Sviluppo di applicazioni desktop ad alta densità di pixel per Windows

Questo contenuto è destinato agli sviluppatori che cercano di aggiornare le applicazioni desktop per gestire le modifiche del fattore di scala di visualizzazione (punti per pollice o DPI) in modo dinamico, consentendo alle applicazioni di essere nitide su qualsiasi display su cui viene eseguito il rendering.

Per iniziare, se stai creando una nuova app di Windows da zero, ti consigliamo di creare un'applicazione UWP (Universal Windows Platform) . Le applicazioni UWP vengono ridimensionate automaticamente e dinamicamente per ogni visualizzazione in cui sono in esecuzione.

Applicazioni desktop che usano tecnologie di programmazione Windows meno recenti (programmazione Win32 non elaborata, Windows Form, Windows Presentation Framework (macchine virtuali Windows) e così via. non è in grado di gestire automaticamente il ridimensionamento DPI senza ulteriori attività di sviluppo. Senza questo lavoro, le applicazioni appariranno sfocate o di dimensioni non corrette in molti scenari di utilizzo comuni. Questo documento fornisce contesto e informazioni su ciò che è coinvolto nell'aggiornamento di un'applicazione desktop per il rendering corretto.

Visualizza fattore di scala e DPI

Con l'avanzare della tecnologia di visualizzazione, i produttori di pannelli di visualizzazione hanno compresso un numero crescente di pixel in ogni unità di spazio fisico sui loro pannelli. Ciò ha fatto sì che i punti per pollice (DPI) dei moderni pannelli di visualizzazione fossero molto più elevati rispetto al passato. In passato, la maggior parte dei display aveva 96 pixel per pollice lineare dello spazio fisico (96 DPI); nel 2017, i display con quasi 300 DPI o superiori sono immediatamente disponibili.

La maggior parte dei framework dell'interfaccia utente desktop legacy presuppone che il dpi di visualizzazione non cambierà durante la durata del processo. Questo presupposto non è più valido, poiché i DPI dei display possono comunemente cambiare più volte durante il ciclo di vita di un processo dell'applicazione. Alcuni scenari comuni in cui il fattore di scala di visualizzazione/DPI cambia:

  • Configurazioni con più monitor in cui ogni visualizzazione ha un fattore di scala diverso e l'applicazione viene spostata da uno schermo a un altro (ad esempio un display 4K e un display a 1080p)
  • Ancoraggio e scollegamento di un portatile con valori DPI alti con un display esterno con valori DPI bassi (o viceversa)
  • Connessione tramite Desktop remoto da un portatile/tablet con valori DPI elevati a un dispositivo con valori DPI bassi (o viceversa)
  • Modifica delle impostazioni del fattore di scalabilità di visualizzazione durante l'esecuzione delle applicazioni

In questi scenari, le applicazioni UWP si ridisegnano automaticamente per il nuovo DPI. Per impostazione predefinita, e senza lavoro aggiuntivo per sviluppatori, le applicazioni desktop non lo fanno. Le applicazioni desktop che non eseguono questo lavoro aggiuntivo per rispondere alle modifiche DPI possono apparire sfocate o non correttamente ridimensionate all'utente.

Modalità di riconoscimento DPI

Le applicazioni desktop devono indicare a Windows se supportano il ridimensionamento DPI. Per impostazione predefinita, il sistema considera le applicazioni desktop non compatibili con DPI e ridimensiona le relative finestre tramite stretching bitmap. Impostando una delle modalità di riconoscimento DPI disponibili seguenti, le applicazioni possono indicare esplicitamente a Windows come vogliono gestire il ridimensionamento DPI:

DPI non a conoscenza

Le applicazioni non compatibili con DPI vengono visualizzate con un valore DPI fisso di 96 (100%). Ogni volta che queste applicazioni vengono eseguite su uno schermo con una scala di visualizzazione maggiore di 96 DPI, Windows estenderà la bitmap dell'applicazione alle dimensioni fisiche previste. Ciò comporta la visualizzazione sfocata dell'applicazione.

Consapevolezza DPI del sistema

Le applicazioni desktop compatibili con il DPI di sistema ricevono in genere il DPI del monitor principale collegato al momento dell'accesso dell'utente. Durante l'inizializzazione, il layout dell'interfaccia utente viene eseguito in modo appropriato (controlli di ridimensionamento, scelta delle dimensioni del carattere, caricamento di asset e così via) usando tale valore DPI di sistema. Di conseguenza, le applicazioni con riconoscimento del DPI di sistema non vengono ridimensionate da Windows (tramite ingrandimento della bitmap) sui display che eseguono il rendering a quel singolo valore DPI. Quando l'applicazione viene spostata su un display con un fattore di scala diverso, oppure se il fattore di scala del display cambia per qualsiasi altro motivo, Windows ridimensionerà tramite bitmap le finestre dell'applicazione, facendole apparire sfocate. In effetti, le applicazioni desktop consapevoli del DPI di sistema vengono visualizzate in modo nitido solo con un solo fattore di scala del display, diventando sfocate ogni volta che il DPI cambia.

Consapevolezza DPI Per-Monitor e Per-Monitor (V2)

È consigliabile aggiornare le applicazioni desktop per usare la modalità di riconoscimento DPI per monitor, consentendo loro di eseguire immediatamente il rendering corretto ogni volta che cambia il valore DPI. Quando un'applicazione segnala a Windows che vuole essere eseguita in questa modalità, Windows non estenderà l'applicazione quando cambia il valore DPI, inviando invece WM_DPICHANGED alla finestra dell'applicazione. È quindi intera responsabilità dell'applicazione adeguare autonomamente il ridimensionamento al nuovo DPI. La maggior parte dei framework dell'interfaccia utente usati dalle applicazioni desktop (controlli comuni di Windows (comctl32), Windows Form, Windows Presentation Framework e così via. non supportano il ridimensionamento DPI automatico, richiedendo agli sviluppatori di ridimensionare e riposizionare il contenuto delle finestre stesse.

Esistono due versioni di Per-Monitor consapevolezza che un'applicazione può registrarsi come: versione 1 e versione 2 (PMv2). La registrazione di un processo come in esecuzione in modalità di riconoscimento PMv2 comporta:

  1. L'applicazione riceve una notifica quando cambia il valore DPI (sia i HWND di primo livello che figlio)
  2. L'applicazione visualizza i pixel non elaborati di ogni visualizzazione
  3. L'applicazione non viene mai ridimensionata come bitmap da Windows
  4. Ridimensionamento DPI automatico dell'area non client (barra del titolo della finestra, barre di scorrimento e così via) da parte di Windows
  5. Finestre di dialogo Win32 (da CreateDialog) ridimensionate automaticamente da Windows in base ai DPI
  6. Risorse bitmap generate dal tema nei controlli comuni (caselle di controllo, sfondi dei pulsanti e così via) sottoposte automaticamente a rendering con il fattore di scala DPI appropriato

Quando è in esecuzione in modalità di riconoscimento Per-Monitor v2, le applicazioni ricevono una notifica quando il valore DPI è cambiato. Se un'applicazione non viene ridimensionata per il nuovo dpi, l'interfaccia utente dell'applicazione apparirà troppo piccola o troppo grande (a seconda della differenza nei valori DPI precedenti e nuovi).

Nota

Per-Monitor consapevolezza V1 (PMv1) è molto limitata. È consigliabile che le applicazioni usino PMv2.

La tabella seguente illustra il rendering delle applicazioni in scenari diversi:

Modalità di riconoscimento DPI Versione di Windows introdotta Visualizzazione dpi dell'applicazione Comportamento al cambio di DPI
Ignaro N/D Tutti i display sono 96 DPI Stiramento della bitmap (sfocata)
Sistema Vista Tutti gli schermi hanno lo stesso VALORE DPI (dpi della visualizzazione primaria al momento dell'avvio della sessione utente corrente) Stiramento della bitmap (sfocata)
Per-Monitor 8.1 DPI della visualizzazione in cui si trova principalmente la finestra dell'applicazione
  • L'HWND di primo livello viene notificato della modifica del DPI
  • Nessun ridimensionamento DPI di alcun elemento dell'interfaccia utente.

Per-Monitor V2 Windows 10 Creators Update (1703) DPI della visualizzazione in cui si trova principalmente la finestra dell'applicazione
  • Gli HWND di primo livello e gli HWND figlio vengono notificati della modifica del DPI

Ridimensionamento DPI automatico di:
  • Area non client
  • Bitmap disegnate con il tema nei controlli comuni (comctl32 V6)
  • Dialoghi (CreateDialog)

Consapevolezza DPI per monitor (V1)

La modalità di riconoscimento DPI Per-Monitor V1 (PMv1) è stata introdotta con Windows 8.1. Questa modalità di riconoscimento DPI è molto limitata e offre solo le funzionalità elencate di seguito. È consigliabile che le applicazioni desktop usino Per-Monitor modalità di riconoscimento v2, supportate in Windows 10 1703 o versione successiva.

Il supporto iniziale per la consapevolezza per monitor offre solo le applicazioni seguenti:

  1. Gli HWND di primo livello ricevono una notifica di una modifica del DPI e viene inoltre fornita loro una nuova dimensione suggerita
  2. Windows non estenderà l'interfaccia utente dell'applicazione
  3. L'applicazione vede tutti i display in pixel fisici (vedere la virtualizzazione)

In Windows 10 1607 o versione successiva, le applicazioni PMv1 possono anche chiamare EnableNonClientDpiScaling durante WM_NCCREATE per richiedere che Windows ridimensiona correttamente l'area non client della finestra.

Supporto per il ridimensionamento DPI per monitor in base al framework o alla tecnologia dell'interfaccia utente

La tabella seguente mostra il livello di supporto di riconoscimento DPI per monitor offerto da vari framework dell'interfaccia utente di Windows a partire da Windows 10 1703:

Framework/Tecnologia Appoggiare Versione del sistema operativo Ridimensionamento DPI gestito da Altre informazioni
Piattaforma UWP (Universal Windows Platform) Completo 1607 Framework dell'interfaccia utente UWP (Universal Windows Platform)
Controlli comuni Win32 grezzi V6 (comctl32.dll)
  • Messaggi di notifica della modifica del DPI inviati a tutti gli HWND
  • Gli asset disegnati dal tema vengono visualizzati correttamente nei controlli comuni
  • Ridimensionamento DPI automatico per i dialoghi
1703 Applicazione esempio di GitHub
Windows Forms Ridimensionamento DPI automatico limitato per monitor per alcuni controlli 1703 Framework dell'interfaccia utente Supporto per valori DPI elevati in Windows Forms
Windows Presentation Framework (macchine virtuali Windows) Le applicazioni macchine virtuali Windows native ridimensionano macchine virtuali Windows ospitate in altri framework e altri framework ospitati in macchine virtuali Windows non vengono ridimensionati automaticamente 1607 Framework dell'interfaccia utente esempio di GitHub
GDI Nessuno N/D Applicazione Vedi scalabilità GDI per valori DPI elevati
GDI+ Nessuno N/D Applicazione Vedere ridimensionamento di High-DPI GDI
MFC Nessuno N/D Applicazione N/D

Aggiornamento di applicazioni esistenti

Per aggiornare correttamente un'applicazione desktop esistente per gestire correttamente il ridimensionamento DPI, è necessario aggiornarla in modo che, almeno, le parti importanti dell'interfaccia utente vengano aggiornate per rispondere alle modifiche dpi.

La maggior parte delle applicazioni desktop viene eseguita in modalità di riconoscimento DPI di sistema. Le applicazioni compatibili con il DPI di sistema vengono in genere ridimensionate in base al DPI dello schermo primario (lo schermo in cui si trovava l'area di notifica al momento dell'avvio della sessione di Windows). Quando cambia l'impostazione DPI, Windows ingrandirà l'interfaccia utente di queste applicazioni tramite ridimensionamento bitmap, con il risultato che spesso appariranno sfocate. Quando si aggiorna un'applicazione compatibile con DPI di sistema per diventare compatibile con dpi per monitor, il codice che gestisce il layout dell'interfaccia utente deve essere aggiornato in modo che venga eseguito non solo durante l'inizializzazione dell'applicazione, ma anche ogni volta che viene ricevuta una notifica di modifica DPI (WM_DPICHANGED nel caso di Win32). Ciò comporta in genere la revisione di eventuali presupposti nel codice che l'interfaccia utente deve essere ridimensionata una sola volta.

Inoltre, nel caso della programmazione Win32, molte API Win32 non hanno alcun contesto DPI o di visualizzazione, quindi restituiscono solo valori relativi alla dpi di sistema. Può essere utile usare il codice per cercare alcune di queste API e sostituirle con varianti compatibili con DPI. Alcune delle API comuni con varianti compatibili con DPI sono:

Versione DPI singola versione per monitor
GetSystemMetrics GetSystemMetricsForDpi
AdjustWindowRectEx AdjustWindowRectExForDpi
SystemParametersInfo SystemParametersInfoForDpi
GetDpiForMonitor GetDpiForWindow

È inoltre consigliabile cercare nella base di codice le dimensioni codificate in modo statico che presuppongono un DPI costante, sostituendole con codice che tenga correttamente conto del ridimensionamento DPI. Di seguito è riportato un esempio che incorpora tutti questi suggerimenti:

Esempio:

L'esempio seguente illustra un caso Win32 semplificato per la creazione di un HWND figlio. La chiamata a CreateWindow presuppone che l'applicazione sia in esecuzione a 96 DPI (USER_DEFAULT_SCREEN_DPI costante) e che le dimensioni e la posizione del pulsante non siano corrette in dpi superiori:

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); 
} 

Il codice aggiornato seguente mostra:

  1. Il codice di creazione della finestra ridimensiona la posizione e le dimensioni dell'HWND figlio in base ai DPI della finestra padre
  2. Rispondere alla modifica del DPI riposizionando e ridimensionando l'HWND figlio
  3. Dimensioni codificate in modo statico eliminate e sostituite con codice che si adatta alle modifiche del 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; 

Quando si aggiorna un'applicazione compatibile con DPI di sistema, alcuni passaggi comuni da seguire sono:

  1. Contrassegnare il processo come compatibile con DPI per monitor (V2) usando un manifesto dell'applicazione (o un altro metodo, a seconda dei framework dell'interfaccia utente usati).
  2. Rendere riutilizzabile la logica del layout dell'interfaccia utente e spostarla dal codice di inizializzazione dell'applicazione in modo che possa essere riutilizzata quando si verifica una modifica DPI (WM_DPICHANGED nel caso della programmazione Di Windows (Win32).
  3. Invalidare qualsiasi codice che presuppone che i dati sensibili dpi (DPI/fonts/sizes/etc.) non debbano mai essere aggiornati. È pratica molto comune memorizzare nella cache le dimensioni dei caratteri e i valori DPI durante l'inizializzazione del processo. Quando si aggiorna un'applicazione in modo che diventi compatibile con dpi per monitor, è necessario rivalutare i dati sensibili ai valori DPI ogni volta che viene rilevato un nuovo DPI.
  4. Quando si verifica una modifica del DPI, ricaricare (o ri-rasterizzare) tutte le risorse bitmap per il nuovo DPI oppure, facoltativamente, ridimensionare le risorse bitmap attualmente caricate fino alle dimensioni corrette.
  5. Usare grep per individuare le API che non supportano i DPI per monitor e sostituirle con API che supportano i DPI per monitor (ove applicabile). Esempio: sostituire GetSystemMetrics con GetSystemMetricsForDpi.
  6. Testare l'applicazione in un sistema multi-display/multi-DPI.
  7. Per le finestre di primo livello dell'applicazione che non è possibile aggiornare correttamente alla scala DPI, usare il ridimensionamento DPI in modalità mista (descritto di seguito) per consentire l'estensione bitmap di queste finestre di primo livello dal sistema.

Ridimensionamento DPI in modalità mista (ridimensionamento DPI del sottoprocesso)

Quando si aggiorna un'applicazione per supportare la consapevolezza DPI per monitor, a volte può diventare poco pratico o impossibile aggiornare ogni finestra nell'applicazione in un'unica operazione. Questo può essere semplicemente dovuto al tempo e allo sforzo necessario per aggiornare e testare tutta l'interfaccia utente o perché non si è proprietari di tutto il codice dell'interfaccia utente che è necessario eseguire (se l'applicazione potrebbe caricare l'interfaccia utente di terze parti). In queste situazioni, Windows offre un modo per avvicinarsi gradualmente al mondo della DPI awareness per monitor, consentendoti di eseguire alcune finestre dell'applicazione (solo quelle di primo livello) nella modalità DPI-awareness originale, mentre concentri tempo ed energie sull'aggiornamento delle parti più importanti dell'interfaccia utente.

Di seguito è riportata un'illustrazione dell'aspetto che potrebbe essere simile al seguente: si aggiorna l'interfaccia utente principale dell'applicazione ("Finestra principale" nell'illustrazione) per l'esecuzione con riconoscimento DPI per monitor mentre si eseguono altre finestre nella modalità esistente ("Finestra secondaria").

differenze nella scalabilità dpi tra le modalità di riconoscimento

Prima dell'aggiornamento dell'anniversario di Windows 10 (1607), la modalità di riconoscimento DPI di un processo era una proprietà a livello di processo. A partire dall'aggiornamento dell'anniversario di Windows 10, questa proprietà può ora essere impostata per finestra di primo livello. (Le finestre figlie devono continuare a corrispondere alla scala della finestra padre.) Una finestra di primo livello è definita come una finestra senza padre. Si tratta in genere di una finestra "normale" con pulsanti minimi, ingrandisci e chiudi. Lo scenario a cui è destinata la DPI awareness del sottoprocesso è quello in cui l'interfaccia utente secondaria viene ridimensionata da Windows (con bitmap ingrandita), mentre puoi concentrare tempo e risorse sull'aggiornamento dell'interfaccia utente primaria.

Per abilitare la consapevolezza dpi del sottoprocesso, chiamare SetThreadDpiAwarenessContext prima e dopo qualsiasi chiamata di creazione della finestra. La finestra creata verrà associata alla consapevolezza DPI impostata tramite SetThreadDpiAwarenessContext. Utilizzare la seconda chiamata per ripristinare la consapevolezza DPI del thread corrente.

L'uso del ridimensionamento DPI del sottoprocesso consente di fare affidamento su Windows per eseguire alcune delle operazioni di ridimensionamento DPI per l'applicazione, ma può aumentare la complessità dell'applicazione. È importante comprendere gli svantaggi di questo approccio e la natura delle complessità introdotte. Per altre informazioni sulla DPI awareness del sottoprocesso, vedi scalabilità DPI in modalità mista e API con riconoscimento DPI.

Test delle modifiche

Dopo aver aggiornato l'applicazione affinché supporti i DPI per monitor, è importante verificare che risponda correttamente alle variazioni di DPI in un ambiente con DPI misti. Alcune specifiche per il test includono:

  1. Spostamento delle finestre dell'applicazione avanti e indietro tra le visualizzazioni di valori DPI diversi
  2. Avvio dell'applicazione in visualizzazione di valori DPI diversi
  3. Modifica del fattore di scala del monitor mentre l'applicazione è in esecuzione
  4. Modificando lo schermo usato come schermo principale, disconnettendosi da Windows, quindi testando di nuovo l'applicazione dopo aver eseguito nuovamente l'accesso. Ciò è particolarmente utile per individuare il codice che utilizza dimensioni/misure codificate in modo statico.

Problemi comuni (Win32)

Non usare il rettangolo suggerito fornito in WM_DPICHANGED

Quando Windows invia alla finestra dell'applicazione un messaggio di WM_DPICHANGED, questo messaggio include un rettangolo suggerito da usare per ridimensionare la finestra. È fondamentale che l'applicazione usi questo rettangolo per ridimensionarsi, come segue:

  1. Assicurarsi che il cursore del mouse rimanga nella stessa posizione relativa della finestra durante il trascinamento tra i display
  2. Impedisci alla finestra dell'applicazione di accedere a un ciclo di modifica dpi ricorsivo in cui una modifica DPI attiva una modifica DPI successiva, che attiva un'altra modifica DPI.

Se sono presenti requisiti specifici dell'applicazione che impediscono di usare il rettangolo suggerito fornito da Windows nel messaggio WM_DPICHANGED, vedere WM_GETDPISCALEDSIZE. Questo messaggio può essere usato per assegnare a Windows una dimensione desiderata che si desidera utilizzare una volta apportata la modifica dpi, evitando comunque i problemi descritti in precedenza.

Mancanza di documentazione sulla virtualizzazione

Quando un HWND o un processo usa la modalità non DPI-aware o DPI-aware di sistema, Windows può ridimensionarlo come bitmap. Quando ciò accade, Windows ridimensiona e converte le informazioni sensibili al DPI provenienti da alcune API nello spazio di coordinate del thread chiamante. Ad esempio, se un thread dpi-unware esegue una query sulle dimensioni dello schermo durante l'esecuzione su uno schermo con valori DPI elevati, Windows virtualizzerà la risposta fornita all'applicazione come se lo schermo fosse in unità DPI 96. In alternativa, quando un thread compatibile con DPI di sistema interagisce con una visualizzazione con valori DPI diversi rispetto a quando è stata avviata la sessione dell'utente corrente, Windows ridimensiona alcune chiamate API nello spazio di coordinate usato da HWND se fosse in esecuzione con il fattore di scala DPI originale.

Quando si aggiorna correttamente l'applicazione desktop alla scalabilità DPI, può essere difficile sapere quali chiamate API possono restituire valori virtualizzati in base al contesto del thread; queste informazioni non sono attualmente sufficientemente documentate da Microsoft. Tenere presente che, se si richiama una qualsiasi API di sistema da un contesto del thread non compatibile con DPI o compatibile con i DPI di sistema, il valore restituito potrebbe essere virtualizzato. Di conseguenza, assicurati che il thread venga eseguito nel contesto DPI previsto quando interagisci con lo schermo o con le singole finestre. Quando si modifica temporaneamente il contesto DPI di un thread usando SetThreadDpiAwarenessContext, assicurarsi di ripristinare il contesto precedente al termine per evitare di causare comportamenti errati altrove nell'applicazione.

molte API Windows non hanno un contesto DPI

Molte API Windows legacy non includono un contesto DPI o HWND come parte della relativa interfaccia. Di conseguenza, gli sviluppatori spesso devono eseguire operazioni aggiuntive per gestire il ridimensionamento di qualsiasi informazione sensibile ai DPI, ad esempio dimensioni, punti o icone. Ad esempio, gli sviluppatori che usano LoadIcon devono usare icone caricate con estensione bitmap o usare API alternative per caricare le icone di dimensioni corrette per i valori DPI appropriati, ad esempio LoadImage.

A partire da Windows 11 (Build 22000), le applicazioni che creano cursori dai dati in memoria possono usare SetThreadCursorCreationScaling per abilitare il ridimensionamento DPI automatico per monitor, simile ai cursori caricati dalle risorse del modulo.

Reimpostazione forzata della consapevolezza DPI a livello di processo

In generale, la modalità di riconoscimento DPI del processo non può essere modificata dopo l'inizializzazione del processo. Windows può tuttavia modificare forzatamente la modalità di consapevolezza DPI del processo se si tenta di interrompere il requisito che tutti i HWND in un albero delle finestre abbiano la stessa modalità di riconoscimento DPI. In tutte le versioni di Windows, a partire da Windows 10 1703, non è possibile avere diversi HWND in un albero HWND eseguito in diverse modalità di riconoscimento DPI. Se si tenta di creare una relazione figlio-padre che viola questa regola, la consapevolezza DPI dell'intero processo può essere reimpostata. Questo può essere attivato da:

  1. Una chiamata a CreateWindow in cui la finestra padre specificata ha una modalità di consapevolezza DPI diversa da quella del thread chiamante.
  2. Chiamata SetParent in cui le due finestre sono associate a diverse modalità di riconoscimento DPI.

La tabella seguente illustra cosa accade se si tenta di violare questa regola:

Operazione Windows 8.1 Windows 10 (1607 e versioni precedenti) Windows 10 (1703 e versioni successive)
CreateWindow (In-Proc) N/D Figlio eredita (modalità mista) Figlio eredita (modalità mista)
CreateWindow (Cross-Proc) reimpostazione forzata (del processo del chiamante) Figlio eredita (modalità mista) reimpostazione forzata (del processo del chiamante)
SetParent (In-Proc) N/D reimpostazione forzata (del processo corrente) fail (ERROR_INVALID_STATE)
SetParent (Cross-Proc) reimpostazione forzata (del processo della finestra figlio) reimpostazione forzata (del processo della finestra figlio) reimpostazione forzata (del processo della finestra figlio)

Riferimento API per DPI elevati

Ridimensionamento DPI in modalità mista e API compatibili con DPI.