Développement d’applications de bureau DPI élevé sur Windows

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

Pour commencer, si vous créez une application Windows 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 incorrectement dimensionnées dans de nombreux scénarios d’utilisation courants. Ce document fournit du contexte et des informations sur ce qui est impliqué dans la mise à jour d’une application de bureau pour s’afficher correctement.

Afficher l’indicateur DPI du facteur & d’échelle

À mesure que 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 (DPI) de panneaux d’affichage modernes beaucoup plus élevés qu’ils n’ont historiquement été. Auparavant, la plupart des affichages avaient 96 pixels par pouce linéaire d’espace physique (96 DPI); 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 que 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 DPIS d’affichage qui changent généralement plusieurs fois dans la durée de vie d’un processus d’application. Certains scénarios courants où le facteur d’échelle d’affichage/DPI change sont les suivants :

  • 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 suppression d’un ordinateur portable DPI élevé avec un affichage externe à faible DPI (ou vice versa)
  • Connexion via le Bureau à distance à partir d’un ordinateur portable/tablette haute DPI à un appareil à faible DPI (ou vice versa)
  • 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 nouveau DPI. Par défaut, et sans travail de développeur supplémentaire, les applications de bureau ne le font pas. Les applications de bureau qui n’effectuent pas ce travail supplémentaire pour répondre aux modifications DPI peuvent apparaître floues ou incorrectement dimensionnées à l’utilisateur.

Mode de sensibilisation à l’indicateur DPI

Les applications de bureau doivent indiquer Windows s’ils prennent en charge la mise à l’échelle DPI. Par défaut, le système considère que les applications de bureau n’ont pas connaissance et les images bitmap étendent leurs fenêtres. En définissant l’un des modes de sensibilisation DPI disponibles suivants, les applications peuvent indiquer explicitement Windows comment elles souhaitent gérer la mise à l’échelle DPI :

IPI non conscient

DPI ignore les applications qui s’affichent à 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 DPI, Windows étend la bitmap de l’application à la taille physique attendue. Cela entraîne l’affichage flou de l’application.

Prise en charge de l’IPI système

Les applications de bureau qui sont des ppp système prenant en charge reçoivent généralement le DPI du moniteur connecté principal à partir de l’heure de connexion utilisateur. Lors de l’initialisation, ils ont mis 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 le rendu des affichages à ce seul ppp. Lorsque l’application est déplacée vers un affichage avec un facteur d’échelle différent ou si le facteur d’échelle d’affichage change autrement, Windows mettez à 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 ne s’affichent que de manière nette à un seul facteur d’échelle d’affichage, en devenant floues chaque fois que l’indicateur de données change.

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

Il est recommandé que les applications de bureau soient mises à jour pour utiliser le mode de sensibilisation aux PPP par moniteur, ce qui leur permet de s’afficher immédiatement correctement chaque fois que le DPI change. Lorsqu’une application signale à Windows qu’elle souhaite s’exécuter dans ce mode, Windows n’étend pas l’application lorsque le DPI change, au lieu d’envoyer WM_DPICHANGED à la fenêtre de l’application. Il est ensuite la responsabilité complète de l’application de gérer le redimensionnement lui-même pour le nouveau DPI. La plupart des frameworks d’interface utilisateur utilisés par les applications de bureau (Windows contrôles courants (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 comme : version 1 et version 2 (PMv2). L’inscription d’un processus en mode de sensibilisation PMv2 entraîne les résultats suivants :

  1. L’application en cours d’notification lorsque l’indicateur DPI change (à la fois les HWND de niveau supérieur et enfant)
  2. L’application qui voit 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 DPI par Windows
  5. Boîtes de dialogue Win32 (à partir de CreateDialog) mise à l’échelle automatiquement par Windows
  6. Ressources bitmap dessinées par thème dans les contrôles courants (cases à cocher, arrière-plan des boutons, etc.) affichées automatiquement au facteur d’échelle DPI approprié

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

Remarque

la sensibilisation Per-Monitor 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 à l’indicateur DPI version Windows introduite Vue de l’application de L’PPP Comportement sur le changement d’indicateur de performance
Ignorer N/A Tous les affichages sont 96 DPI Stretching bitmap (flou)
Système Vista Tous les affichages ont le même ppp (l’indicateur DPI de l’affichage principal au moment où la session utilisateur actuelle a été démarrée) Stretching bitmap (flou)
Per-Monitor 8.1 L’indicateur DPI de l’affichage sur lequel se trouve principalement la fenêtre d’application
  • Le HWND de niveau supérieur est averti de la modification de L’indicateur DPI
  • Aucune mise à l’échelle DPI des éléments d’interface utilisateur.

Per-Monitor V2 Windows 10 Creators Update (1703) L’indicateur DPI de l’affichage sur lequel se trouve principalement la fenêtre d’application
  • Les HWND de niveau supérieur et enfant sont avertis du changement 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)

Prise en charge par moniteur (V1) DPI

Per-Monitor mode de sensibilisation DPI V1 (PMv1) a été introduit avec Windows 8.1. Ce mode de sensibilisation à l’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 versions ultérieures.

La prise en charge initiale de la sensibilisation par moniteur n’offre que 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 affiche 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 mettre correctement à l’échelle la zone non cliente de la fenêtre.

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

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

Framework / Technologie Support Version du SE Mise à l’échelle DPI gérée par En savoir plus
Plateforme Windows universelle (UWP) Complète 1607 Infrastructure d’interface utilisateur Plateforme Windows universelle (UWP)
Raw Win32/Common Controls V6 (comctl32.dll)
  • Messages de notification de modification DPI envoyés à tous les disques HWND
  • Les ressources dessinées par thème s’affichent correctement dans les contrôles courants
  • Mise à l’échelle automatique des ppp pour les boîtes de dialogue
1703 Application exemple GitHub
Windows Forms Mise à l’échelle 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 infrastructures hébergées dans WPF ne sont pas automatiquement mises à l’échelle 1607 Infrastructure d’interface utilisateur exemple GitHub
GDI None N/A Application Voir mise à l’échelle de GDI high-DPI
GDI+ None N/A Application Voir mise à l’échelle de GDI high-DPI
MFC None N/A Application N/A

Mise à jour des applications existantes

Pour mettre à jour une application de bureau existante afin de gérer correctement la mise à l’échelle des PPP, elle doit être mise à jour de telle sorte 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 prise en charge de l’ppp système. Les applications prenant en charge le système sont généralement mises à l’échelle vers le DPI de l’affichage principal (l’affichage sur lequel la barre d’état système a été installée au moment où la session Windows a été démarrée). Lorsque le DPI change, Windows étend l’interface utilisateur de ces applications, ce qui entraîne souvent un flou. Lors de la mise à jour d’une application prenant en charge l’IPI système pour devenir consciente par moniteur-DPI, le code qui gère la disposition de l’interface utilisateur doit être mis à jour de sorte qu’il soit effectué non seulement lors de l’initialisation de l’application, mais aussi 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 DPI ou d’affichage afin qu’elles retournent uniquement des valeurs relatives à l’IPI système. Il peut être utile de grep par le biais de votre code pour rechercher certaines de ces API et les remplacer par des variantes prenant en charge les ppp. Certaines des API courantes qui ont des variantes prenant en charge les PPP sont les suivantes :

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 codebase qui supposent une constante DPI, 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 DPI, et que ni la taille ni la position du bouton ne seront correctes au niveau des API 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. L’indicateur de mise à l’échelle du code de création de fenêtre met à l’échelle la position et la taille du HWND enfant pour l’indicateur DPI 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épondent 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, 96); 
    int dpiScaledY = MulDiv(INITIALY_96DPI, iDpi, 96); 
    int dpiScaledWidth = MulDiv(INITIALWIDTH_96DPI, iDpi, 96); 
    int dpiScaledHeight = MulDiv(INITIALHEIGHT_96DPI, iDpi, 96); 
    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 l’ppp système, certaines étapes courantes à suivre sont les suivantes :

  1. Marquez le processus comme étant compatible avec L’IPI par moniteur (V2) à l’aide d’un manifeste d’application (ou d’une autre méthode, selon les framework 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 d’application de telle sorte 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 à l’ppp (DPI/polices/sizes/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 DPI au moment de l’initialisation du processus. Lors de la mise à jour d’une application pour devenir prise en charge par moniteur, les données sensibles à l’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 nouveau DPI ou, éventuellement, l’image bitmap étire les ressources actuellement chargées à la taille correcte.
  5. Grep pour les API qui ne sont pas Per-Monitor prise en charge d’un ppp et les remplacent par des API prenant en charge Per-Monitor DPI (le cas échéant). Exemple : remplacez GetSystemMetrics par GetSystemMetricsForDpi.
  6. Testez votre application sur un système multi-affichage/multi-DPI.
  7. Pour toutes les fenêtres de niveau supérieur de votre application que vous ne parvenez pas à mettre à jour correctement à l’échelle DPI, utilisez la mise à l’échelle DPI en mode mixte (décrite ci-dessous) pour autoriser l’étirage bitmap de ces fenêtres de niveau supérieur par le système.

Mixed-Mode mise à l’échelle DPI (mise à l’échelle DPI sous-processus)

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 étape. 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 l’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 DPI d’origine, tandis que vous concentrez votre temps et votre énergie à mettre à jour les parties 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 la prise en charge des PPP par moniteur pendant que vous exécutez d’autres fenêtres en mode existant (« Fenêtre secondaire »).

differences in dpi scaling between awareness modes

Avant la mise à jour anniversaire Windows 10 (1607), le mode de sensibilisation aux PPP 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 niveau supérieur. (Les 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 « régulière » avec des boutons de réduction, d’optimisation et de fermeture. Le scénario pour lequel la prise en charge des ppp sous-processus est destinée à avoir une interface utilisateur secondaire mise à l’échelle 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 sous-processus DPI, appelez SetThreadDpiAwarenessContext avant et après les appels de création de fenêtre. La fenêtre créée sera associée à la sensibilisation DPI que vous définissez via SetThreadDpiAwarenessContext. Utilisez le deuxième appel pour restaurer la prise en charge du DPI du thread actuel.

Lorsque vous utilisez la mise à l’échelle DPI sous-processus, vous pouvez vous appuyer sur Windows pour effectuer une partie de la mise à l’échelle DPI pour votre application, ce qui 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 sensibilisation aux sous-processus DPI, consultez les API de mise à l’échelle et de prise en charge des PPP en mode mixte.

Test de vos modifications

Une fois que vous avez mis à jour votre application pour devenir informé par moniteur, il est important de valider que votre application répond correctement aux modifications de DPI 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-test de 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)

N’utilisez pas le rectangle suggéré fourni dans WM_DPICHANGED

Lorsque Windows envoie à votre 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 cela :

  1. Vérifiez que le curseur de la souris reste à la même position relative sur la fenêtre lors du glisser entre les affichages
  2. Empêchez la fenêtre d’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 la modification d’ppp effectuée, tout en évitant les problèmes décrits ci-dessus.

Absence de documentation sur la virtualisation

Lorsqu’un HWND ou un processus s’exécute en tant qu’indicateur DPI non conscient ou qu’il est conscient du système, il peut être étiré 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 définition interroge la taille de l’écran lors de l’exécution sur un affichage high-DPI, Windows virtualise la réponse donnée à l’application comme si l’écran se trouvait dans 96 unités DPI. Par ailleurs, lorsqu’un thread prenant en charge l’indicateur DPI système interagit avec un affichage différent de celui utilisé lors du démarrage de la session de l’utilisateur actuel, Windows effectue une mise à l’échelle de certaines API dans l’espace de coordonnées que le HWND utilise s’il s’exécute à son facteur d’échelle DPI d’origine.

Lorsque vous mettez à jour votre application de bureau vers une mise à l’échelle DPI correctement, il peut difficile de savoir quels appels d’API peuvent retourner des valeurs virtualisées en fonction du contexte de thread; ces informations ne sont actuellement pas suffisamment documentées par Microsoft. N’oubliez pas que si vous appelez n’importe quelle API système à partir d’un contexte de thread sans connaissance du système ou 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 DPI que vous attendez lors de l’interaction avec l’écran ou les fenêtres individuelles. Lorsque vous modifiez temporairement le contexte DPI d’un thread à l’aide de SetThreadDpiAwarenessContext, veillez à restaurer l’ancien contexte lorsque vous avez terminé pour éviter d’entraîner un comportement incorrect ailleurs dans votre application.

De nombreuses API Windows n’ont pas de contexte DPI

De nombreuses API de Windows héritées n’incluent pas de contexte DPI 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 de toutes les informations sensibles aux PPP, telles que les tailles, les points ou les icônes. Par exemple, les développeurs qui utilisent LoadIcon doivent soit étendre les icônes chargées en bitmap, soit utiliser d’autres API pour charger correctement des icônes de taille appropriée pour l’api DPI 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’IPI de votre processus ne peut pas être modifié après l’initialisation du processus. Windows pouvez toutefois modifier de force le mode de sensibilisation de l’PPP de votre processus si vous tentez de briser l’exigence que tous les disques HWND dans une arborescence de fenêtres aient le même mode de sensibilisation aux PPP. Sur toutes les versions de Windows, à partir de Windows 10 1703, il n’est pas possible d’avoir des HWND différents dans une arborescence HWND exécutée dans différents modes de prise de conscience DPI. Si vous tentez de créer une relation parente enfant 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. Appel SetParent où les deux fenêtres sont associées à différents modes de sensibilisation aux ppp.

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 L’enfant hérite (mode mixte) L’enfant hérite (mode mixte)
CreateWindow (Cross-Proc) Réinitialisation forcée (processus de l’appelant) L’enfant hérite (mode mixte) Réinitialisation forcée (processus de l’appelant)
SetParent (in-Proc) N/A Réinitialisation forcée (du processus actuel) Échec (ERROR_INVALID_STATE)
SetParent (Cross-Proc) Réinitialisation forcée (processus de la fenêtre enfant) Réinitialisation forcée (processus de la fenêtre enfant) Réinitialisation forcée (processus de la fenêtre enfant)

Informations de référence sur l’API DPI élevée

API de mise à l’échelle en mode mixte et API prenant en charge les PPP.