Hvis du åbner Stifinder, og alt ser sløret ud, og du ikke kan finde kompatibilitetsfanen i systemfilen, er du ikke alene. Hi-DPI (DPI) skalering i Windows blander moderne og ældre komponenter, og det fører til mærkelige resultater: sløret tekst, uforholdsmæssigt store kontroller og inkonsekvent adfærd mellem apps.
Situationen forværres, når du skifter skærm eller ændrer skaleringsfaktoren. UWP-apps fungerer normalt fint, men Win32-apps kræver lidt omhu.Her kombinerer vi officiel Microsoft-teori med praktiske cases (Explorer, Office, SSMS, Chrome, Adobe) og kode for at hjælpe dig med at forstå, hvad der sker, og hvordan du skal reagere.
Hvorfor er der ingen kompatibilitetsfane til explorer.exe?
Det er normalt, at kompatibilitetsfanen ikke vises i C:/Windows/explorer.exe. Stifinder er en del af Windows-shellen og er beskyttet, så dens indstillinger administreres ikke som i andre apps. Derfor kan du f.eks. ikke fremtvinge en DPI-tilsidesættelse fra dens egenskaber.
Hvis Stifinder og Kontrolpanel ser slørede ud, er årsagen ikke en enkelt skjult knap. Problemet ligger i, hvordan Windows skalerer den ældre brugerflade når der er DPI-ændringer, eller der bruges en skærm med høj densitet. Styring af dette afhænger af forståelse af DPI-genkendelsestilstande og systemindstillinger til korrigering af slørede apps.
PPP og skalafaktor: Det grundlæggende at forstå
Efterhånden som pixeltætheden stiger, Moderne paneler er gået fra 96 DPI til tal tæt på 300 DPI eller mereFor at gøre alt læsbart anvender Windows en skaleringsfaktor, og apps skal reagere på den.
Mange Win32-kodebaser var baseret på en antagelse, der ikke længere holder stik: PPP'en blev fastsat gennem hele processens levetidI dag, med bærbare computere, der docker og skifter mellem 1080p- og 4K-skærme, ændres DPI undervejs, nogle gange flere gange i en enkelt session.
Typiske scenarier, hvor DPI eller skaleringsfaktor ændres: flyt vinduer mellem skærme med forskellige skalaer, dock/fradoc din bærbare computer, start Fjernskrivebord fra/til computere med forskellig DPI, eller tryk på skaleringsknappen i Indstillinger, mens apps er åbne.
DPI-bevidsthedstilstande i Windows
Desktop-apps skal fortælle Windows, om de ved, hvordan skalering skal håndteres. Hvis de ikke gør det, antager systemet 96 DPI og strækker bitmap'en., som ser sløret ud. Disse er de vigtigste tilstande:
Ubevidst PPPAppen gengiver med 96 DPI (100%). På større skærme zoomer Windows bitmapbilledet til den forventede fysiske størrelse, og brugerfladen bliver sløret.
Systembevidst- Appen tager DPI'en for den primære skærm ved login og tilpasser dens brugergrænseflade i overensstemmelse hermed. Hvis du flytter den til en anden skærm med en anden DPI, strækker Windows den, og den bliver sløret.Den ser kun skarp ud ved den DPI, den blev initialiseret til.
Skærmbevidst (pr. skærm, V1)Introduceret i Windows 8.1. Vinduer på øverste niveau modtager besked om DPI-ændringWindows skalerer ikke bitmap-billedet, og appen ser fysiske pixels på hver skærm. Det er funktionelt, men begrænset.
Pr. skærm v2Anbefales siden Windows 10 1703. Indeholder vigtige forbedringer: notifikationer til HWND'er på topniveau og sekundære niveauerWindows skalerer automatisk ikke-klientområdet (titel, rullepaneler), CreateDialog-dialoger og temategnede ressourcer (comctl32 V6) til den korrekte DPI. Appen ser rå pixels, og Windows skalerer den aldrig igen.
UWP vs Win32: Hvorfor nogle ting ser godt ud, og andre ikke gør
Hvis du bygger en app fra bunden og vælger UWP, er frameworket Tegner automatisk om baseret på skærmens DPIDer er ikke andet at gøre. Tidligere teknologier (ren Win32, Windows Forms, WPF, GDI, MFC osv.) skalerer dog ikke af sig selv; du skal programmere det eller de vil virke slørede, for små eller uforholdsmæssige.
Dette er mærkbart i hverdagens detaljer i den klassiske brugergrænseflade: når systemet indstilles til 200% Rullepanelet kan blive tykkere, og nogle knapper kan krympe, med kurver og kanter, der ser mærkelige ud. Denne type mangler påvirker Explorer og andre dele af Win32-skallen, nej til UWP.
Hvilke frameworks skalerer bedst (og hvilke gør ikke)
Ifølge Microsoft varierer skærmunderstøttelse afhængigt af teknologien. UWP har fuld støtte og selve frameworket håndterer skalering. Win32 med Common Controls V6 (comctl32.dll) i 1703 inkluderer notifikationer til alle HWND'er, Ressourcer med temaer, der omtegnes til den korrekte PPP, og dialoger, der skalerer sig selv.
Windows Forms har en begrænset automatisk skalering af skærmen for visse kontroller, mens native WPF skalerer godt, hvis du forbliver i WPF, men sameksistens med andre hostede frameworks skalerer ikke automatisk. GDI, GDI+ og MFC understøtter ikke af sig selv: logikken skal implementeres af applikationen.
Opgrader din desktop-app til Per-Monitor (V2)
Minimumsmålet er, at Med hver DPI-ændring ændres størrelsen på vigtige dele af brugergrænsefladenHvis din app i øjeblikket er systembevidst, vil Windows strække den og få den til at se sløret ud, når du skalerer den. For at undgå dette skal du konvertere den til Per-Monitor V2 og tegne den om på stedet.
Praktiske retningslinjer for migration: vigtige trin for at undgå strækning
- Deklarerer pr. skærm V2 i manifestet eller brug den relevante API, afhængigt af dit framework.
- Uddrag layoutlogikken fra opstart og omdanne dem til genbrugelige rutiner, som du også kalder på WM_DPICHANGED.
- Reevaluer PPP-følsomme data (skrifttyper, størrelser, målinger) ved hver DPI-ændring; gem dem ikke i hardcache.
- Genindlæs eller remaster bitmaps til den nye skala eller, hvis det ikke er muligt, accepterer bitmap-skalering for disse ressourcer.
- Erstatter uvidende API'er efter DPI-varianter: for eksempel GetSystemMetrics → GetSystemMetricsForDpi.
- Test i miljøer med flere niveauer af PPP (flere skærme, RDP, hotskalering).
- For Windows kan du endnu ikke opdatere, bruger blandet skalering med trådgenkendelse.
Forenklet Win32-eksempelNaivt tilfælde (antager 96 DPI), der opretter en knap og ser dårligt ud ved høj DPI:
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);
}Tilpasset version: skalerer position og størrelse med GetDpiForWindow og reagerer på WM_DPICHANGED:
#define INITIALX_96DPI 50
#define INITIALY_96DPI 50
#define INITIALWIDTH_96DPI 100
#define INITIALHEIGHT_96DPI 50
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: {
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: {
HWND hWndButton = FindWindowEx(hWnd, NULL, NULL, NULL);
if (hWndButton != NULL) { UpdateButtonLayoutForDpi(hWndButton); }
} break;Blandet skalering og trådbevidsthed
Det kan være urealistisk at opdatere en hel stor brugergrænseflade på én gang. Det er her, blandet tilstand (DPI pr. tråd)Du kan lade nogle vinduer på øverste niveau være i deres oprindelige tilstand, mens du moderniserer resten.
Fra og med Windows 10 1607, DPI-genkendelse kan indstilles pr. vindue på øverste niveauUndervinduer skal arve deres forældres tilstand. Brug SetThreadDpiAwarenessContext før du opretter vinduet for at knytte det til til den ønskede tilstand og gendan den bagefter.
C++-mønster Sådan låser du trådens DPI-kontekst under oprettelse:
class DpiAwarenessContextBlock {
public:
DpiAwarenessContextBlock(DPI_AWARENESS_CONTEXT dpiContext) noexcept {
m_contextReversalType = SetThreadDpiAwarenessContext(dpiContext);
}
~DpiAwarenessContextBlock() {
SetThreadDpiAwarenessContext(m_contextReversalType);
}
private:
DPI_AWARENESS_CONTEXT m_contextReversalType;
};Tilsvarende administreret (C#) mønster til skift og gendannelse af kontekst i blokke: nyttig i løsninger med flere vinduer.
class DPIContextBlock : IDisposable {
private DPI_AWARENESS_CONTEXT resetContext;
public DPIContextBlock(DPI_AWARENESS_CONTEXT contextSwitchTo) {
resetContext = SetThreadDpiAwarenessContext(contextSwitchTo);
}
public void Dispose() { SetThreadDpiAwarenessContext(resetContext); }
}Test du ikke bør springe over og typiske fejl
For at bekræfte, at din app reagerer korrekt, skal du flytte den mellem skærme med forskellige skalaer, start den direkte i den ene eller den anden, skift skaleringsfaktoren, mens appen kører, og skift startskærmen, log ud og prøv igen.
Almindelige fejl:
- Ignorer foreslået rektangel i WM_DPICHANGEDBrug dette til at ændre størrelse og undgå DPI-løkker og markørspring.
- Dårligt dokumenteret virtualiseringHvis du kalder API'er fra en uvidende tråd, kan Windows virtualisere værdier. Skift konteksten med SetThreadDpiAwarenessContext, og husk at gendanne den.
- PPP kontekstløse API'erFor ikoner, størrelser, metrikker ... brug varianter som LoadImage i stedet for LoadIcon eller GetSystemMetricsForDpi i stedet for GetSystemMetrics.
- Tvungen nulstilling af procesgenkendelseForældre- og underordnede objekter med forskellige DPI-tilstande kan ikke findes i det samme HWND-træ. Handlinger som CreateWindow/SetParent med inkompatible tilstande kan fremtvinge en nulstilling eller mislykkes.
Office: Hvad det gør, og hvordan det integreres problemfrit
Office 2016 og nyere opdateres, når skalaen ændres, men skalerbarhedsløsninger skal justeres for at tegne korrekt. Hvis DPI-indstillingen påvirker dig, vil du se dårligt placerede vinduer, kontroller uden for stedet og skrifttyper eller billeder med forkerte størrelser.
Relevante tilstande i Office:
- Uvidendealtid 96 DPI; alt er strakt.
- SystembevidstDPI'en for den primære skærm tages ved opstart; ved efterfølgende ændringer strækkes Windows.
- Pr. skærmTopniveau modtager notifikationer og tegner sig selv om. I v2 modtager døtrene dem også, men Office bruger ikke PMv2.
Trådkontekst: Hovedtråden i Office placeres i Per-Monitor. Hvis du opretter ekstra tråde, tvinger Office dem til at udføre overvågning pr. skærmHvis du forventer en anden kontekst, skal du ændre den med SetThreadDpiAwarenessContext. I Office-tilbagekald, konteksten kommer ind som systembevidstjuster den til dit vindue.
Topniveau vs. underordnede: Dine topniveauvinduer kan gå i enhver tilstand, du vælger, og modtag underretninger; sekundære filer skal respektere genkendelsen af hovedfilen. I Windows 1709 var datterfilerne Per-Monitor; siden 1803 kan Office brug blandet tilstand for at forbedre kompatibiliteten (selvom det kan se sløret ud på grund af strækning).
Nyttige indstillinger for brugere: Aktivér skærmkompatibilitetstilstand i Office Tving systembevidsthed (alt strakt, mulig sløring, men konsistent). I Windows 10 1803+ er systemindstillingen til Ret slørede apps Det hjælper også, hvis din løsning ikke er godt repræsenteret.
Typer af udvidelsesmuligheder og nuancer:
- VSTOUndervinduer skal matche forældrenes bevidsthedstilstand (brug GetWindowDpiAwarenessContext). Vinduer på øverste niveau kan indstilles til enhver ønsket tilstand. Du kan implementere en formular, der reagerer på WM_DPICHANGED, og skalakontroller og kilder i OnDpiÆndretHændelse.
- COM pluginsFor vinduer på øverste niveau skal du oprette en DPI-kontekstblok, før du opretter vinduet, og håndtere WM_DPICHANGED.
- ActiveX i vinduer: reagerer på WM_SIZE; Du kan tjekke GetDpiForWindow og genberegn positioner og kilder.
- Vinduesløs ActiveXI designtilstand kan containeren returnere 0 i hDC, og der er ingen pålidelig PPP; i runtime, Brug den HWND, som Office returnerer til dig at konsultere PPP og skalaen.
- OLEDer er begrænsninger i blandede scenarier; nyere versioner af Office tillader lokal aktivering med betingelser baseret på DPI-konteksten og den udseende-/kompatibilitetsindstilling, som brugeren har valgt.
- Webtilføjelser: køre i en browserkontrol; anvende de samme responsive teknikker som på nettet.
SSMS på 4K-skærme: eksternt manifest og alternativer
På UHD-computere er det almindeligt, at SQL Server Management Studio ser sløret ud i ældre versioner. En klassisk måde var aktiver eksterne manifester med registreringsdatabasenøglen PreferExternalManifest og placer en ssms.exe.manifest-fil i installationsmappen for at gennemtvinge PPP-genkendelse.
Genvej til den fremgangsmåde: Opret nøglen i HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide med navnet PreferExternalManifest (DWORD=1), gem manifestet i stien til ssms.exe med UTF-8-kodning og genstart. Betaunderstøttelse af høj DPI blev introduceret i SSMS 16.3, og ikonerne blev forbedret i SSMS 17, men resultaterne varierede afhængigt af version og konfiguration.
Et andet nyttigt værktøj er Process Explorer (Sysinternals) for at tilføje DPI Aware-kolonnen og kontrollere, om en proces er Ubevidst, Systembevidst eller Per-Monitor. På denne måde kan du kontrollere, om din justering trådte i kraft.
Hurtigt alternativ uden manifester: i Eksekverbare egenskaberUnder fanen Kompatibilitet skal du markere indstillingen "Overskriv skaleringsadfærd ved høj DPI" og indstille "Skalering udført af" til "Program". Dette gennemtvinger tilstanden pr. skærm og forhindrer Windows i at strække sig, når DPI'en ændres. I mange tilfælde retter det SSMS-sløring uden at røre registreringsdatabasen.
Referencer til Process Explorer-kolonner: Uvidende (alle ved 96 DPI, strakt af systemet), Systembevidst (bruger initial DPI, strækker sig derefter ved ændringer) og Pr. skærm (tegnet igen ved ændring). Hver forklarer, hvorfor en app fremstår skarp eller sløret afhængigt af scenariet.
Chrome og Adobe i Hi-DPI: Hvad du kan forvente
Chromes skrifttypegengivelse på Windows har været et problem i årevis. Rettelser blev introduceret i udviklerversioner (som Canary med DirectWrite dengang), der forbedrede skarpheden betydeligt på Hi-DPI-skærme, dog på bekostning af mulige lejlighedsvise fejl eller højere CPU-forbrug i tidlige builds.
I den forrige generation af Adobe-pakken, Photoshop kunne vise den lille brugerfladeAdobe tilføjede en 200% UI-mulighed, der delvist løser problemet i nyere versioner; med ældre versioner skulle man leve med små menuer eller bruge genveje.
I InDesign og Illustrator skete det modsatte: korrekt størrelse, men sløretLøsningen var at deaktivere automatisk skalering i Kompatibilitet (genvejsegenskaber) med "Deaktiver skærmskalering ved brug af høje DPI-indstillinger", hvilket resulterede i en mindre, men skarpere brugergrænseflade.
Endnu en Photoshop-mærkværdighed: forældede eller tredoblede værktøjerJustering af størrelsen på elementer til en brugerdefineret værdi (f.eks. 149 % eller 151 % i stedet for 150 %) under "Gør tekst og andre elementer større eller mindre" kan bringe dit websted tilbage på sporet.
Hvis du leder efter alternativer, GIMP tilbyder en gratis og kraftfuld mulighed som med den rigtige konfiguration fungerer godt i miljøer med høj tæthed.
Tilbage til Stifinder: Hvad du kan gøre fra systemet
Selvom du ikke kan røre kompatibiliteten i explorer.exe, Windows 10 og nyere versioner leveres med to redningslinjer for den samlede oplevelse:
- Indstillinger > System > SkærmIndstil den anbefalede skaleringsfaktor, og undgå usædvanlige værdier, medmindre de opfylder specifikke behov. For computere med hyppige skærmskift er det bedst log ud og log ind igen efter større ændringer.
- Indstillinger > System > Skærm > Avancerede skaleringsindstillingerSlå "Lad Windows forsøge at rette apps, så de ikke er slørede" til. Dette hjælper med ældre apps når du skifter skærme eller skalaer.
Derudover kan du for hver app (undtagen Explorer) åbne dens egenskaber og bruge "Overskriv skaleringsadfærd ved høj DPI" til at vælge "Applikation", "System" eller "System (forbedret)" efter behov. Det er en effektiv ressource, når en specifik app modstår og du kan ikke ændre dens kode.
Med alt ovenstående i tankerne er det store billede klart: UWP'er tilpasser sig selv, Win32'er tilpasser sig også godt, og resten skal justeres.Explorer og andre dele af skallen slæber historiske beslutninger med sig, men økosystemet tilbyder genveje og API'er til at omgå dem.
