Partager via

Développement d’applications de bureau haute résolution sur Windows

  • Article

Ce contenu est destiné aux développeurs qui cherchent à mettre à jour des applications de bureau pour gérer les changements de facteur d’échelle d’affichage (points par pouce ou PPP) dynamiquement, ce qui permet à leurs applications d’être nettes sur n’importe quel affichage sur lequel ils sont affichés.

Pour commencer, si vous créez une application Windows à partir de zéro, il est vivement recommandé de créer une application plateforme Windows universelle (UWP). Les applications UWP sont automatiquement mises à l’échelle pour chaque affichage sur lequel elles s’exécutent.

Applications de bureau utilisant des technologies de programmation Windows plus anciennes (programmation Win32 brute, Windows Forms, Windows Presentation Framework (WPF), etc.) ne peuvent pas gérer automatiquement la mise à l’échelle DPI sans travail de développeur supplémentaire. Sans ce type de travail, les applications apparaissent floues ou mal dimensionnées dans de nombreux scénarios d’utilisation courants. Ce document fournit un contexte et des informations sur ce qui est impliqué dans la mise à jour d’une application de bureau pour s’afficher correctement.

Afficher le facteur d’échelle & PPP

Comme la technologie d’affichage a progressé, les fabricants de panneaux d’affichage ont emballé un nombre croissant de pixels dans chaque unité d’espace physique sur leurs panneaux. Cela a entraîné des points par pouce (PPP) de panneaux d’affichage modernes beaucoup plus élevés qu’ils n’ont historiquement été. Dans le passé, la plupart des affichages avaient 96 pixels par pouce linéaire d’espace physique (96 PPP) ; en 2017, les affichages avec près de 300 PPP ou versions ultérieures sont facilement disponibles.

La plupart des infrastructures d’interface utilisateur de bureau héritées ont des hypothèses intégrées selon laquelle l’indicateur DPI d’affichage ne changera pas pendant la durée de vie du processus. Cette hypothèse n’est plus vraie, avec des DP DPI d’affichage qui changent généralement plusieurs fois pendant toute la durée de vie d’un processus d’application. Voici quelques scénarios courants dans lesquels le facteur d’échelle d’affichage/les modifications DPI sont les suivantes :

  • Configurations à plusieurs moniteurs où chaque affichage a un facteur d’échelle différent et l’application est déplacée d’un affichage à un autre (par exemple, un affichage 4K et un affichage 1080p)
  • Ancrage et dédocrage d’un ordinateur portable haute résolution avec un affichage externe low-DPI (ou vice versa)
  • Connexion via le Bureau à distance à partir d’un ordinateur portable/tablette haute résolution à un appareil à faible résolution (ou inversement)
  • Modification des paramètres de facteur d’affichage lors de l’exécution des applications

Dans ces scénarios, les applications UWP se redessinent automatiquement pour le nouvel ppp. Par défaut, et sans travail de développeur supplémentaire, les applications de bureau ne le font pas. Les applications de bureau qui ne font pas ce travail supplémentaire pour répondre aux modifications DPI peuvent apparaître floues ou incorrectement dimensionnées pour l’utilisateur.

Mode de sensibilisation aux ppp

Les applications de bureau doivent indiquer à Windows s’ils prennent en charge la mise à l’échelle ppp. Par défaut, le système considère que les applications de bureau ne sont pas au courant et que les bitmaps étendent leurs fenêtres. En définissant l’un des modes de sensibilisation aux ppp disponibles suivants, les applications peuvent explicitement indiquer à Windows comment elles souhaitent gérer la mise à l’échelle des PPP :

Ppp non conscient

Les applications sans résolution ne sont pas rendues à une valeur DPI fixe de 96 (100%). Chaque fois que ces applications sont exécutées sur un écran avec une échelle d’affichage supérieure à 96 PPP, Windows étend la bitmap de l’application à la taille physique attendue. Cela entraîne l’affichage flou de l’application.

Sensibilisation aux ppp système

Les applications de bureau prenant en charge les ppp système reçoivent généralement l’ppp du moniteur connecté principal à partir de l’heure de connexion de l’utilisateur. Lors de l’initialisation, ils mettent en place leur interface utilisateur de manière appropriée (contrôles de dimensionnement, choix des tailles de police, chargement des ressources, etc.) à l’aide de cette valeur DPI système. Par conséquent, les applications prenant en charge les ppp système ne sont pas mises à l’échelle (bitmap étirées) par Windows sur les affichages au niveau de ce même ppp. Lorsque l’application est déplacée vers un affichage avec un autre facteur d’échelle ou si le facteur d’échelle d’affichage change autrement, Windows met à l’échelle les fenêtres de l’application, ce qui les rend floues. Efficacement, les applications de bureau prenant en charge les ppp système s’affichent uniquement de manière nette à un seul facteur d’échelle d’affichage, ce qui devient flou chaque fois que l’ppp change.

sensibilisation aux Per-Monitor et aux Per-Monitor (V2) DPI

Il est recommandé que les applications de bureau soient mises à jour pour utiliser le mode de sensibilisation ppp par moniteur, ce qui leur permet de s’afficher immédiatement correctement chaque fois que l’ppp change. Lorsqu’une application signale à Windows qu’elle souhaite s’exécuter dans ce mode, Windows n’étend pas l’application lorsque le ppp change, au lieu d’envoyer WM_DPICHANGED à la fenêtre de l’application. Il incombe ensuite à l’application de gérer le redimensionnement lui-même pour le nouvel PPP. La plupart des frameworks d’interface utilisateur utilisés par les applications de bureau (contrôles courants Windows (comctl32), Windows Forms, Windows Presentation Framework, etc.) ne prennent pas en charge la mise à l’échelle automatique des PPP, ce qui oblige les développeurs à redimensionner et repositionner le contenu de leurs fenêtres eux-mêmes.

Il existe deux versions de Per-Monitor conscience qu’une application peut s’inscrire en tant que : version 1 et version 2 (PMv2). L’inscription d’un processus en mode de sensibilisation PMv2 entraîne :

  1. L’application est avertie lorsque le DPI change (les HWND de niveau supérieur et enfants)
  2. Application affichant les pixels bruts de chaque affichage
  3. L’application n’étant jamais mise à l’échelle bitmap par Windows
  4. Zone automatique non cliente (légende de fenêtre, barres de défilement, etc.) Mise à l’échelle ppp par Windows
  5. Boîtes de dialogue Win32 (à partir de CreateDialog) mise à l’échelle automatique par Windows
  6. Ressources bitmap dessinées par thème dans les contrôles courants (cases à cocher, arrière-plans de bouton, etc.) affichées automatiquement au niveau du facteur d’échelle DPI approprié

Lors de l’exécution en mode de sensibilisation à Per-Monitor v2, les applications sont averties lorsque leur ppp a changé. Si une application ne se redimensionne pas pour la nouvelle ppp, l’interface utilisateur de l’application apparaît trop petite ou trop grande (en fonction de la différence dans les valeurs précédentes et nouvelles DPI).

Note

Per-Monitor la prise en charge de V1 (PMv1) est très limitée. Il est recommandé que les applications utilisent PMv2.

Le tableau suivant montre comment les applications s’affichent dans différents scénarios :

Mode de sensibilisation aux ppp Version de Windows introduite Vue de l’application de ppp Comportement sur le changement d’ppp
Inconscient N/A Tous les affichages sont 96 PPP Stretching bitmap (flou)
Système Vue Tous les affichages ont le même PPP (ppp de l’affichage principal au moment du démarrage de la session utilisateur actuelle) Stretching bitmap (flou)
Per-Monitor 8.1 Ppp de l’affichage sur lequel se trouve principalement la fenêtre d’application
  • Le HWND de niveau supérieur est averti du changement DPI
  • Aucune mise à l’échelle ppp des éléments d’interface utilisateur.
Per-Monitor V2 Windows 10 Creators Update (1703) Ppp de l’affichage sur lequel se trouve principalement la fenêtre d’application
  • Les de niveau supérieur et les HWND enfants sont avertis des modifications DPI

mise à l’échelle automatique des ppp :
  • Zone non cliente
  • Bitmaps dessinées par thème dans les contrôles courants (comctl32 V6)
  • Boîtes de dialogue (CreateDialog)

Reconnaissance des PPP par moniteur (V1)

Per-Monitor mode de sensibilisation aux ppp V1 (PMv1) a été introduit avec Windows 8.1. Ce mode de prise en charge des PPP est très limité et offre uniquement les fonctionnalités répertoriées ci-dessous. Il est recommandé que les applications de bureau utilisent Per-Monitor mode de sensibilisation v2, pris en charge sur Windows 10 1703 ou version ultérieure.

La prise en charge initiale de la prise en charge par moniteur offre uniquement les applications suivantes :

  1. Les HWND de niveau supérieur sont avertis d’une modification DPI et ont fourni une nouvelle taille suggérée
  2. Windows n’étend pas l’interface utilisateur de l’application
  3. L’application voit tous les affichages en pixels physiques (voir virtualisation)

Sur Windows 10 1607 ou version ultérieure, les applications PMv1 peuvent également appeler EnableNonClientDpiScaling pendant WM_NCCREATE pour demander que Windows met correctement à l’échelle la zone non cliente de la fenêtre.

Prise en charge de la mise à l’échelle DPI par moniteur par UI Framework / Technologie

Le tableau ci-dessous montre le niveau de prise en charge de la prise en charge des PPP par moniteur proposé par diverses infrastructures d’interface utilisateur Windows à partir de Windows 10 1703 :

Framework / Technologie Soutien Version du système d’exploitation Mise à l’échelle DPI gérée par Lecture plus poussée
Plateforme Windows universelle (UWP) Plein 1607 Infrastructure d’interface utilisateur plateforme Windows universelle (UWP)
Raw Win32/Common Controls V6 (comctl32.dll)
  • Messages de notification de modification ppp envoyés à tous les HWND
  • Les ressources dessinées par thème s’affichent correctement dans les contrôles courants
  • Mise à l’échelle automatique des ppp pour les dialogues
 1703 Application exemple de GitHub
Windows Forms Mise à l’échelle d’ppp automatique par moniteur limitée pour certains contrôles 1703 Infrastructure d’interface utilisateur prise en charge élevée des ppp dans windows Forms
Windows Presentation Framework (WPF) Les applications WPF natives mettez à l’échelle WPF hébergées dans d’autres frameworks et d’autres frameworks hébergés dans WPF ne sont pas mis à l’échelle automatiquement 1607 Infrastructure d’interface utilisateur exemple de GitHub
GDI Aucun N/A Application Voir GDI High-DPI Mise à l’échelle
GDI+ Aucun N/A Application Voir GDI High-DPI Mise à l’échelle
MFC Aucun N/A Application N/A

Mise à jour des applications existantes

Pour mettre à jour une application de bureau existante pour gérer correctement la mise à l’échelle des ppp, elle doit être mise à jour afin que, au minimum, les parties importantes de son interface utilisateur soient mises à jour pour répondre aux modifications d’ppp.

La plupart des applications de bureau s’exécutent en mode de sensibilisation aux ppp système. Les applications prenant en charge le système sont généralement mises à l’échelle vers l’écran principal (l’affichage sur lequel la barre d’état système a été installée au moment du démarrage de la session Windows). Lorsque le DPI change, Windows étend l’interface utilisateur de ces applications, ce qui les rend souvent flous. Lors de la mise à jour d’une application prenant en charge les ppp système pour qu’elle devienne consciente par moniteur-PPP, le code qui gère la disposition de l’interface utilisateur doit être mis à jour afin qu’elle soit effectuée non seulement lors de l’initialisation de l’application, mais également chaque fois qu’une notification de modification DPI (WM_DPICHANGED dans le cas de Win32) est reçue. Cela implique généralement de revoir toutes les hypothèses dans le code que l’interface utilisateur ne doit être mise à l’échelle qu’une seule fois.

En outre, dans le cas de la programmation Win32, de nombreuses API Win32 n’ont pas de contexte d’ppp ou d’affichage, de sorte qu’elles retournent uniquement des valeurs par rapport à l’API système. Il peut être utile de parcourir votre code pour rechercher certaines de ces API et les remplacer par des variantes prenant en charge les ppp. Voici quelques-unes des API courantes qui ont des variantes prenant en charge les PPP :

Version DPI unique version Per-Monitor
GetSystemMetrics GetSystemMetricsForDpi
AdjustWindowRectEx AdjustWindowRectExForDpi
SystemParametersInfo SystemParametersInfoForDpi
GetDpiForMonitor GetDpiForWindow

Il est également judicieux de rechercher des tailles codées en dur dans votre base de code qui supposent un ppp constant, en les remplaçant par du code qui compte correctement pour la mise à l’échelle DPI. Voici un exemple qui incorpore toutes ces suggestions :

Exemple:

L’exemple ci-dessous montre un cas Win32 simplifié de création d’un HWND enfant. L’appel à CreateWindow part du principe que l’application s’exécute à 96 ppp (constanteUSER_DEFAULT_SCREEN_DPI), et que ni la taille ni la position du bouton ne seront correctes à des DPI supérieures :

case WM_CREATE: 
{ 
    // Add a button 
    HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me",  
        WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,  
        50,  
        50,  
        100,  
        50,  
        hWnd, (HMENU)NULL, NULL, NULL); 
}

Le code mis à jour ci-dessous montre :

  1. Ppp de création de fenêtre mise à l’échelle de la position et de la taille du HWND enfant pour l’ppp de sa fenêtre parente
  2. Réponse au changement DPI en repositionnant et en redimensionnant le HWND enfant
  3. Tailles codées en dur supprimées et remplacées par du code qui répond aux modifications DPI
#define INITIALX_96DPI 50 
#define INITIALY_96DPI 50 
#define INITIALWIDTH_96DPI 100 
#define INITIALHEIGHT_96DPI 50 

// DPI scale the position and size of the button control 
void UpdateButtonLayoutForDpi(HWND hWnd) 
{ 
    int iDpi = GetDpiForWindow(hWnd); 
    int dpiScaledX = MulDiv(INITIALX_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, USER_DEFAULT_SCREEN_DPI); 
    SetWindowPos(hWnd, hWnd, dpiScaledX, dpiScaledY, dpiScaledWidth, dpiScaledHeight, SWP_NOZORDER | SWP_NOACTIVATE); 
} 
 
... 
 
case WM_CREATE: 
{ 
    // Add a button 
    HWND hWndChild = CreateWindow(L"BUTTON", L"Click Me",  
        WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, 
        0, 
        0, 
        0, 
        0, 
        hWnd, (HMENU)NULL, NULL, NULL); 
    if (hWndChild != NULL) 
    { 
        UpdateButtonLayoutForDpi(hWndChild); 
    } 
} 
break; 
 
case WM_DPICHANGED: 
{ 
    // Find the button and resize it 
    HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL); 
    if (hWndButton != NULL) 
    { 
        UpdateButtonLayoutForDpi(hWndButton); 
    } 
} 
break;

Lors de la mise à jour d’une application prenant en charge les ppp système, voici quelques étapes courantes à suivre :

  1. Marquez le processus comme prenant en charge les PPP par moniteur (V2) à l’aide d’un manifeste d’application (ou d’une autre méthode, selon les framework(s) d’interface utilisateur utilisés.
  2. Rendez la logique de disposition de l’interface utilisateur réutilisable et déplacez-la hors du code d’initialisation de l’application afin qu’elle puisse être réutilisée lorsqu’une modification DPI se produit (WM_DPICHANGED dans le cas de la programmation Windows (Win32).
  3. Invalidez tout code qui suppose que les données sensibles aux ppp (PPP/polices/tailles/etc.) n’ont jamais besoin d’être mises à jour. Il s’agit d’une pratique très courante pour mettre en cache les tailles de police et les valeurs ppp lors de l’initialisation du processus. Lors de la mise à jour d’une application pour qu’elle prenne en charge les PPP par moniteur, les données sensibles aux ppp doivent être réévaluées chaque fois qu’un nouvel ppp est rencontré.
  4. Lorsqu’une modification DPI se produit, rechargez (ou réétérisez) toutes les ressources bitmap pour le nouvel ppp ou, éventuellement, étirez les ressources actuellement chargées jusqu’à la taille correcte.
  5. Grep pour les API qui ne sont pas Per-Monitor prenant en charge les PPP et les remplace par Per-Monitor API prenant en charge les PPP (le cas échéant). Exemple : remplacez GetSystemMetrics par GetSystemMetricsForDpi.
  6. Testez votre application sur un système multi-affichage/multi-PPP.
  7. Pour toutes les fenêtres de niveau supérieur de votre application que vous ne parvenez pas à mettre à jour correctement à l’échelle ppp, utilisez la mise à l’échelle ppp en mode mixte (décrite ci-dessous) pour autoriser l’étirement bitmap de ces fenêtres de niveau supérieur par le système.

mise à l’échelle d'Mixed-Mode PPP (mise à l’échelle d'Sub-Process PPP)

Lors de la mise à jour d’une application pour prendre en charge la prise en charge des PPP par moniteur, il peut parfois devenir impraticable ou impossible de mettre à jour chaque fenêtre de l’application en une seule fois. Cela peut simplement être dû au temps et à l’effort nécessaire pour mettre à jour et tester toute l’interface utilisateur, ou parce que vous ne possédez pas tout le code de l’interface utilisateur que vous devez exécuter (si votre application charge peut-être une interface utilisateur tierce). Dans ces situations, Windows offre un moyen de faciliter dans le monde de la sensibilisation par moniteur en vous permettant d’exécuter certaines de vos fenêtres d’application (niveau supérieur uniquement) en mode de sensibilisation DPI d’origine, tandis que vous concentrez votre temps et votre énergie à mettre à jour les parties les plus importantes de votre interface utilisateur.

Voici une illustration de ce que cela pourrait ressembler : vous mettez à jour l’interface utilisateur de votre application principale (« Fenêtre principale » dans l’illustration) pour qu’elle s’exécute avec une prise en charge des PPP par moniteur pendant que vous exécutez d’autres fenêtres en mode existant (« Fenêtre secondaire »).

différences de mise à l’échelle des ppp entre les modes de sensibilisation

Avant la mise à jour anniversaire Windows 10 (1607), le mode de prise en charge d’un processus était une propriété à l’échelle du processus. À compter de la mise à jour anniversaire Windows 10, cette propriété peut désormais être définie par fenêtre de de niveau supérieur. (fenêtres enfants doivent continuer à correspondre à la taille de mise à l’échelle de leur parent.) Une fenêtre de niveau supérieur est définie comme une fenêtre sans parent. Il s’agit généralement d’une fenêtre « normale » avec des boutons de réduction, d’agrandissement et de fermeture. Le scénario pour lequel la prise en charge des ppp de sous-processus est destinée à être mise à l’échelle de l’interface utilisateur secondaire par Windows (bitmap étirée) pendant que vous concentrez votre temps et vos ressources sur la mise à jour de votre interface utilisateur principale.

Pour activer la prise en charge des ppp de sous-processus, appelez SetThreadDpiAwarenessContext avant et après les appels de création de fenêtre. La fenêtre créée est associée à la prise de conscience ppp que vous définissez via SetThreadDpiAwarenessContext. Utilisez le deuxième appel pour restaurer la prise en charge des PPP du thread actuel.

Bien que l’utilisation de la mise à l’échelle ppp sous-processus vous permet de vous appuyer sur Windows pour effectuer une partie de la mise à l’échelle ppp pour votre application, elle peut augmenter la complexité de votre application. Il est important de comprendre les inconvénients de cette approche et de la nature des complexités qu’elle introduit. Pour plus d’informations sur la prise en charge des ppp de sous-processus, consultez Mixed-Mode API prenant en charge la mise à l’échelle et les PPP.

Test de vos modifications

Une fois que vous avez mis à jour votre application pour qu’elle devienne consciente de l’ppp par moniteur, il est important de valider que votre application répond correctement aux modifications apportées aux PPP dans un environnement d’ppp mixte. Voici quelques spécificités à tester :

  1. Déplacement des fenêtres d’application entre les affichages de différentes valeurs DPI
  2. Démarrage de votre application sur les affichages de différentes valeurs DPI
  3. Modification du facteur d’échelle de votre moniteur pendant l’exécution de l’application
  4. Modification de l’affichage que vous utilisez comme affichage principal, déconnexion de Windows, puis re-testez votre application après la connexion. Cela est particulièrement utile pour rechercher du code qui utilise des tailles/dimensions codées en dur.

Pièges courants (Win32)

Pas utiliser le rectangle suggéré fourni dans WM_DPICHANGED

Lorsque Windows envoie une fenêtre d’application à un message WM_DPICHANGED, ce message inclut un rectangle suggéré que vous devez utiliser pour redimensionner votre fenêtre. Il est essentiel que votre application utilise ce rectangle pour se redimensionner, comme suit :

  1. Vérifiez que le curseur de la souris reste dans la même position relative sur la fenêtre lors du glissement entre les affichages
  2. Empêchez la fenêtre de l’application d’entrer dans un cycle de changement de ppp récursif où une modification DPI déclenche une modification DPI ultérieure, ce qui déclenche une autre modification DPI.

Si vous avez des exigences spécifiques à l’application qui vous empêchent d’utiliser le rectangle suggéré que Windows fournit dans le message WM_DPICHANGED, consultez WM_GETDPISCALEDSIZE. Ce message peut être utilisé pour donner à Windows une taille souhaitée que vous souhaitez utiliser une fois que la modification DPI s’est produite, tout en évitant les problèmes décrits ci-dessus.

manque de documentation sur la virtualisation

Lorsqu’un HWND ou un processus s’exécute en tant que ppp non conscient ou que le DPI système est conscient, il peut s’agir d’une bitmap étirée par Windows. Lorsque cela se produit, Windows met à l’échelle et convertit les informations sensibles aux ppp de certaines API en espace de coordonnées du thread appelant. Par exemple, si un thread sans prise en charge DPI interroge la taille de l’écran lors de l’exécution sur un affichage haute résolution, Windows virtualise la réponse donnée à l’application comme si l’écran se trouvait dans 96 unités DPI. Sinon, lorsqu’un thread prenant en charge les ppp système interagit avec un affichage à un autre ppp que celui utilisé lors du démarrage de la session de l’utilisateur actuel, Windows met à l’échelle certains appels d’API dans l’espace de coordonnées que le HWND utiliserait s’il s’exécutait à son facteur d’échelle DPI d’origine.

Lorsque vous mettez à jour votre application de bureau vers une mise à l’échelle ppp correctement, il peut être difficile de savoir quels appels d’API peuvent retourner des valeurs virtualisées en fonction du contexte de thread ; ces informations ne sont pas suffisamment documentées par Microsoft. N’oubliez pas que si vous appelez une API système à partir d’un contexte de thread sans prise en charge de ppp ou sans prise en charge du système, la valeur de retour peut être virtualisée. Par conséquent, assurez-vous que votre thread s’exécute dans le contexte ppp que vous attendez lors de l’interaction avec l’écran ou les fenêtres individuelles. Lorsque vous modifiez temporairement le contexte PPP d’un thread à l’aide de SetThreadDpiAwarenessContext, veillez à restaurer l’ancien contexte lorsque vous avez terminé pour éviter de provoquer un comportement incorrect ailleurs dans votre application.

de nombreuses API Windows n’ont pas de contexte ppp

De nombreuses API Windows héritées n’incluent pas de contexte PPP ou HWND dans le cadre de leur interface. Par conséquent, les développeurs doivent souvent effectuer des tâches supplémentaires pour gérer la mise à l’échelle des informations sensibles aux ppp, telles que les tailles, les points ou les icônes. Par exemple, les développeurs qui utilisent LoadIcon doivent soit des icônes chargées bitmap, soit utiliser d’autres API pour charger des icônes de taille correcte pour la résolution appropriée, comme LoadImage.

réinitialisation forcée de la prise en charge des PPP à l’échelle du processus

En général, le mode de prise en charge de l’PPP de votre processus ne peut pas être modifié après l’initialisation du processus. Toutefois, Windows peut modifier de force le mode de sensibilisation ppp de votre processus si vous tentez de rompre l’exigence que tous les HWND d’une arborescence de fenêtres aient le même mode de prise en charge DPI. Sur toutes les versions de Windows, à partir de Windows 10 1703, il n’est pas possible d’avoir différents HWND dans une arborescence HWND exécutée dans différents modes de prise de conscience DPI. Si vous tentez de créer une relation enfant-parent qui interrompt cette règle, la prise en compte de l’ensemble du processus peut être réinitialisée. Cela peut être déclenché par :

  1. Un appel CreateWindow où la fenêtre parente passée est d’un mode de sensibilisation DPI différent du thread appelant.
  2. Un appel SetParent où les deux fenêtres sont associées à différents modes de prise en charge DPI.

Le tableau ci-dessous montre ce qui se passe si vous tentez de violer cette règle :

Opération Windows 8.1 Windows 10 (1607 et versions antérieures) Windows 10 (1703 et versions ultérieures)
CreateWindow (In-Proc) N/A Enfant hérite (mode mixte) Enfant hérite (mode mixte)
CreateWindow (Cross-Proc) de réinitialisation forcée (du processus de l’appelant) Enfant hérite (mode mixte) de réinitialisation forcée (du processus de l’appelant)
SetParent (In-Proc) N/A de réinitialisation forcée (du processus actuel) Échec (ERROR_INVALID_STATE)
SetParent (Cross-Proc) de réinitialisation forcée (du processus de la fenêtre enfant) de réinitialisation forcée (du processus de la fenêtre enfant) de réinitialisation forcée (du processus de la fenêtre enfant)

Informations de référence sur l’API haute résolution

Mixed-Mode api prenant en charge la mise à l’échelle et les API prenant en charge les PPP.