Fönsterfunktioner

I den här översikten beskrivs funktioner i fönster, till exempel fönstertyper, tillstånd, storlek och position.

• fönstertyper
  • Överlappade Windows-
  • Popup-windows
  • underordnad Windows-
    • Positionering
    • Urklipp
    • relation till överordnat fönster
    • Meddelanden
  • Layered Windows
  • Message-Only Windows
• • förgrunds- och bakgrundsfönster
  • ägda Windows-
  • Z-Order
• fönstret Visa tillstånd
  • aktivt fönster
  • Inaktiverad Windows-
  • fönstersynlighet
  • Minimerad, Maximerad och Återställd Windows-
• fönsterstorlek och position
  • standardstorlek och position
  • spårningsstorlek
  • systemkommandon
  • storleks- och placeringsfunktioner
  • storleks- och placeringsmeddelanden
• fönsteranimering
• fönsterlayout och spegling
  • dialogrutor och meddelanderutor för spegling
  • spegling av enhetskontexter som inte är associerade med ett fönster
• fönsterförstörelse

Fönstertyper

Det här avsnittet innehåller följande avsnitt som beskriver fönstertyper.

• Överlappade Windows-
• Popup-windows
• underordnad Windows-
• Layered Windows
• Message-Only Windows

Överlappande Windows

Ett överlappande fönster är ett fönster på den översta nivån (icke-underordnat fönster) som har ett namnlist, kantlinje och klientområde. det är tänkt att fungera som ett programs huvudfönster. Den kan också ha en fönstermeny, minimera och maximera knappar och rullningslister. Ett överlappande fönster som används som huvudfönster innehåller vanligtvis alla dessa komponenter.

Genom att ange formatet WS_OVERLAPPED eller WS_OVERLAPPEDWINDOW i funktionen CreateWindowEx skapar ett program ett överlappande fönster. Om du använder formatmallen WS_OVERLAPPED har fönstret ett namnlist och kantlinje. Om du använder WS_OVERLAPPEDWINDOW formatmallen har fönstret ett namnlist, storleksgräns, fönstermeny och minimerar och maximerar knappar.

Popup-fönster

Ett popup-fönster är en särskild typ av överlappande fönster som används för dialogrutor, meddelanderutor och andra tillfälliga fönster som visas utanför programmets huvudfönster. Namnlister är valfria för popup-fönster. I annat fall är popup-fönster samma som överlappande fönster i WS_OVERLAPPED stil.

Du skapar ett popup-fönster genom att ange formatet WS_POPUP i CreateWindowEx. Om du vill inkludera ett namnlist anger du formatet WS_CAPTION. Använd formatmallen WS_POPUPWINDOW för att skapa ett popup-fönster som har en kantlinje och en fönstermeny. Det WS_CAPTION formatet måste kombineras med WS_POPUPWINDOW formatmall för att fönstermenyn ska visas.

Underordnad Windows

Ett underordnat fönster har WS_CHILD formatmall och är begränsat till klientområdet i det överordnade fönstret. Ett program använder vanligtvis underordnade fönster för att dela upp klientområdet i ett överordnat fönster i funktionella områden. Du skapar ett underordnat fönster genom att ange formatet WS_CHILD i funktionen CreateWindowEx.

Ett underordnat fönster måste ha ett överordnat fönster. Det överordnade fönstret kan vara ett överlappande fönster, ett popup-fönster eller till och med ett annat underordnat fönster. Du anger det överordnade fönstret när du anropar CreateWindowEx. Om du anger formatmallen WS_CHILD i CreateWindowEx men inte anger ett överordnat fönster, skapar systemet inte fönstret.

Ett underordnat fönster har ett klientområde men inga andra funktioner, såvida de inte uttryckligen begärs. Ett program kan begära en namnlist, en fönstermeny, minimera och maximera knappar, en kantlinje och rullningslister för ett underordnat fönster, men ett underordnat fönster kan inte ha en meny. Om programmet anger ett menyhandtag, antingen när det registrerar den underordnade fönsterklassen eller skapar det underordnade fönstret, ignoreras menyhandtaget. Om inget kantlinjeformat har angetts skapar systemet ett kantlöst fönster. Ett program kan använda underordnade fönster utan kantlinje för att dela upp ett överordnat fönsters klientområde samtidigt som divisionerna hålls osynliga för användaren.

I det här avsnittet beskrivs följande aspekter av underordnade fönster:

• Positionering
• Urklipp
• relation till överordnat fönster
• Meddelanden

Positionering

Systemet placerar alltid ett underordnat fönster i förhållande till det övre vänstra hörnet i det överordnade fönstrets klientområde. Ingen del av ett underordnat fönster visas någonsin utanför det överordnade fönstrets kantlinjer. Om ett program skapar ett underordnat fönster som är större än det överordnade fönstret eller placerar ett underordnat fönster så att vissa eller hela det underordnade fönstret sträcker sig utanför den överordnades kantlinjer klipper systemet det underordnade fönstret. Den del som ligger utanför det överordnade fönstrets klientområde visas alltså inte. Åtgärder som påverkar det överordnade fönstret kan också påverka det underordnade fönstret enligt följande.

Överordnat fönster	Underordnat fönster
Förstörd	Förstörs innan det överordnade fönstret förstörs.
Dold	Dolt innan det överordnade fönstret är dolt. Ett underordnat fönster visas bara när det överordnade fönstret är synligt.
Rörd	Flyttas med det överordnade fönstrets klientområde. Det underordnade fönstret ansvarar för att måla sitt klientområde efter flytten.
Visad	Visas när det överordnade fönstret visas.

 

Klippning

Systemet klipper inte automatiskt ett underordnat fönster från det överordnade fönstrets klientområde. Det innebär att det överordnade fönstret ritar över det underordnade fönstret om det utför någon ritning på samma plats som det underordnade fönstret. Systemet klipper dock det underordnade fönstret från det överordnade fönstrets klientområde om det överordnade fönstret har WS_CLIPCHILDREN formatmall. Om det underordnade fönstret är klippt kan det överordnade fönstret inte rita över det.

Ett underordnat fönster kan överlappa andra underordnade fönster i samma klientområde. Ett underordnat fönster som delar samma överordnade fönster som ett eller flera andra underordnade fönster kallas för ett syskonfönster. Syskonfönster kan rita i varandras klientområde, såvida inte ett av de underordnade fönstren har WS_CLIPSIBLINGS stil. Om ett underordnat fönster har den här stilen klipps alla delar av dess syskonfönster som ligger i det underordnade fönstret bort.

Om ett fönster har antingen WS_CLIPCHILDREN eller WS_CLIPSIBLINGS stil uppstår en viss prestandaförlust. Varje fönster tar upp systemresurser, så ett program bör inte använda underordnade fönster urskillningslöst. För bästa prestanda bör ett program som behöver dela upp huvudfönstret logiskt göra det i fönsterproceduren i huvudfönstret i stället för med hjälp av underordnade fönster.

Relation till överordnat fönster

Ett program kan ändra det överordnade fönstret i ett befintligt underordnat fönster genom att anropa funktionen SetParent. I det här fallet tar systemet bort det underordnade fönstret från klientområdet i det gamla överordnade fönstret och flyttar det till klientområdet i det nya överordnade fönstret. Om SetParent- anger en NULL- handtag blir skrivbordsfönstret det nya överordnade fönstret. I det här fallet ritas det underordnade fönstret på skrivbordet, utanför kantlinjerna för andra fönster. Funktionen GetParent hämtar ett handtag till ett underordnat fönsters överordnade fönster.

Det överordnade fönstret lämnar en del av klientområdet till ett underordnat fönster, och det underordnade fönstret tar emot alla indata från det här området. Fönsterklassen behöver inte vara samma för vart och ett av de underordnade fönstren i det överordnade fönstret. Det innebär att ett program kan fylla ett överordnat fönster med underordnade fönster som ser annorlunda ut och utför olika uppgifter. En dialogruta kan till exempel innehålla många typer av kontroller, var och en ett underordnat fönster som accepterar olika typer av data från användaren.

Ett underordnat fönster har bara ett överordnat fönster, men en överordnad kan ha valfritt antal underordnade fönster. Varje underordnat fönster kan i sin tur ha underordnade fönster. I den här fönsterkedjan kallas varje underordnat fönster för ett underordnat fönster i det ursprungliga överordnade fönstret. Ett program använder funktionen IsChild för att ta reda på om ett visst fönster är ett underordnat fönster eller ett underordnat fönster i ett visst överordnat fönster.

Funktionen EnumChildWindows räknar upp de underordnade fönstren i ett överordnat fönster. Sedan skickar EnumChildWindows handtaget till varje underordnat fönster till en programdefinierad återanropsfunktion. Underordnade fönster i det angivna överordnade fönstret räknas också upp.

Meddelanden

Systemet skickar ett underordnat fönsters indatameddelanden direkt till det underordnade fönstret. meddelandena skickas inte genom det överordnade fönstret. Det enda undantaget är om det underordnade fönstret har inaktiverats av funktionen EnableWindow. I det här fallet skickar systemet alla indatameddelanden som skulle ha gått till det underordnade fönstret till det överordnade fönstret i stället. Detta gör att det överordnade fönstret kan undersöka indatameddelandena och aktivera det underordnade fönstret, om det behövs.

Ett underordnat fönster kan ha en unik heltalsidentifierare. Underordnade fönsteridentifierare är viktiga när du arbetar med kontrollfönster. Ett program dirigerar en kontrolls aktivitet genom att skicka meddelanden till den. Programmet använder kontrollens underordnade fönsteridentifierare för att dirigera meddelandena till kontrollen. Dessutom skickar en kontroll meddelandemeddelanden till det överordnade fönstret. Ett meddelande innehåller kontrollens underordnade fönsteridentifierare, som den överordnade använder för att identifiera vilken kontroll som skickade meddelandet. Ett program anger den underordnade fönsteridentifieraren för andra typer av underordnade fönster genom att ange parametern hMenu för funktionen CreateWindowEx till ett värde i stället för ett menyhandtag.

Skiktade Windows

Att använda ett skiktat fönster kan avsevärt förbättra prestanda och visuella effekter för ett fönster som har en komplex form, animerar sin form eller vill använda alfablandningseffekter. Systemet skapar och ommålar automatiskt skiktade fönster och fönster i underliggande program. Därför renderas skiktade fönster smidigt, utan att det flimrar typiskt för komplexa fönsterregioner. Dessutom kan skiktade fönster vara delvis genomskinliga, d.v.s. alfablandade.

Om du vill skapa ett skiktat fönster anger du WS_EX_LAYERED utökat fönsterformat när du anropar funktionen CreateWindowEx eller anropar funktionen SetWindowLong för att ange WS_EX_LAYERED när fönstret har skapats. När anropet CreateWindowEx visas inte det skiktade fönstret förrän funktionen SetLayeredWindowAttributes eller UpdateLayeredWindow har anropats för det här fönstret.

Not

Från och med Windows 8 kan WS_EX_LAYERED användas med underordnade fönster och fönster på den översta nivån. Tidigare Windows-versioner stöder endast WS_EX_LAYERED för fönster på den översta nivån.

 

Om du vill ange opacitetsnivån eller transparensfärgnyckeln för ett visst skiktat fönster anropar du SetLayeredWindowAttributes. Efter anropet kan systemet fortfarande be fönstret att måla när fönstret visas eller ändras. Men eftersom systemet lagrar bilden av ett skiktat fönster, kommer systemet inte att be fönstret att måla om delar av det avslöjas som ett resultat av relativa fönsterflyttningar på skrivbordet. Äldre program behöver inte omstrukturera sin målningskod om de vill lägga till genomskinlighets- eller transparenseffekter för ett fönster, eftersom systemet omdirigerar målningen av fönster som kallas SetLayeredWindowAttributes till minnet utanför skärmen och omkompererar det för att uppnå önskad effekt.

För snabbare och effektivare animering eller om alfa per pixel behövs anropar du UpdateLayeredWindow. UpdateLayeredWindow bör främst användas när programmet måste ange formen och innehållet i ett lagerfönster direkt, utan att använda omdirigeringsmekanismen som systemet tillhandahåller via SetLayeredWindowAttributes. Dessutom använder UpdateLayeredWindow direkt minne mer effektivt, eftersom systemet inte behöver det extra minne som krävs för att lagra avbildningen av det omdirigerade fönstret. För maximal effektivitet i animera fönster anropar du UpdateLayeredWindow för att ändra positionen och storleken på ett skiktat fönster. Observera att när SetLayeredWindowAttributes har anropats misslyckas efterföljande UpdateLayeredWindow-anrop tills skiktningsformatbiten har rensats och ställts in igen.

Träfftestning av ett skiktat fönster baseras på fönstrets form och transparens. Det innebär att de områden i fönstret som är färgtangenterade eller vars alfavärde är noll låter musmeddelandena gå igenom. Men om det skiktade fönstret har WS_EX_TRANSPARENT utökad fönsterstil ignoreras formen på det skiktade fönstret och mushändelserna skickas till andra fönster under det skiktade fönstret.

Message-Only Windows

Med ett fönster med endast meddelanden kan du skicka och ta emot meddelanden. Den är inte synlig, har ingen z-ordning, kan inte räknas upp och tar inte emot sändningsmeddelanden. Fönstret skickar helt enkelt meddelanden.

Om du vill skapa ett meddelandefönster anger du HWND_MESSAGE konstant eller ett handtag till ett befintligt meddelandefönster i parametern hWndParent för funktionen CreateWindowEx. Du kan också ändra ett befintligt fönster till ett meddelandefönster genom att ange HWND_MESSAGE i parametern hWndNewParent för funktionen SetParent.

Om du vill hitta fönster med endast meddelanden anger du HWND_MESSAGE i parametern hwndParent för funktionen FindWindowEx. Dessutom söker FindWindowEx endast meddelandefönster och fönster på den översta nivån om både hwndParent och hwndChildAfter parametrarna är NULL-.

Fönsterrelationer

Det finns många sätt som ett fönster kan relatera till användaren eller ett annat fönster. Ett fönster kan vara ett ägt fönster, ett förgrundsfönster eller ett bakgrundsfönster. Ett fönster har också en z-ordning i förhållande till andra fönster. Mer information finns i följande avsnitt:

• förgrunds- och bakgrundsfönster
• ägda Windows-
• Z-Order

Förgrunds- och bakgrundsfönster

Varje process kan ha flera körningstrådar och varje tråd kan skapa fönster. Tråden som skapade fönstret som användaren arbetar med kallas förgrundstråden och fönstret kallas förgrundsfönster. Alla andra trådar är bakgrundstrådar och de fönster som skapas av bakgrundstrådar kallas bakgrundsfönster.

Varje tråd har en prioritetsnivå som avgör hur lång CPU-tid tråden tar emot. Även om ett program kan ange prioritetsnivån för sina trådar, har förgrundstråden normalt en något högre prioritetsnivå än bakgrundstrådarna. Eftersom den har högre prioritet får förgrundstråden mer CPU-tid än bakgrundstrådarna. Förgrundstråden har en normal basprioritet på 9; en bakgrundstråd har en normal basprioritet på 7.

Användaren anger förgrundsfönstret genom att klicka på ett fönster eller genom att använda tangentkombinationen ALT+TAB eller ALT+ESC. Om du vill hämta ett handtag till förgrundsfönstret använder du funktionen GetForegroundWindow. Om du vill kontrollera om programfönstret är förgrundsfönstret jämför du referensen som returneras av GetForegroundWindow med programfönstrets.

Ett program anger förgrundsfönstret med hjälp av funktionen SetForegroundWindow.

Systemet begränsar vilka processer som kan ange förgrundsfönstret. En process kan endast ange förgrundsfönstret om:

• Alla följande villkor är uppfyllda:
  • Processen som anropar SetForegroundWindow tillhör ett skrivbordsprogram, inte en UWP-app eller en Windows Store-app som är utformad för Windows 8 eller 8.1.
  • Förgrundsprocessen har inte inaktiverat anrop till SetForegroundWindow av ett tidigare anrop till funktionen LockSetForegroundWindow.
  • Tidsgränsen för förgrundslåset har upphört att gälla (se SPI_GETFOREGROUNDLOCKTIMEOUT i SystemParametersInfo).
  • Inga menyer är aktiva.
• Dessutom är minst ett av följande villkor sant:
  • Anropsprocessen är förgrundsprocessen.
  • Anropsprocessen startades av förgrundsprocessen.
  • Det finns för närvarande inget förgrundsfönster och därmed ingen förgrundsprocess.
  • Anropsprocessen tog emot den senaste indatahändelsen.
  • Antingen förgrundsprocessen eller anropsprocessen debuggas.

Det är möjligt att en process nekas rätten att ange förgrundsfönstret även om det uppfyller dessa villkor.

En process som kan ange förgrundsfönstret kan aktivera en annan process för att ange förgrundsfönstret genom att anropa funktionen AllowSetForegroundWindow eller genom att anropa funktionen BroadcastSystemMessage med flaggan BSF_ALLOWSFW. Förgrundsprocessen kan inaktivera anrop till SetForegroundWindow genom att anropa funktionen LockSetForegroundWindow.

Ägda Windows

Ett överlappande fönster eller popup-fönster kan ägas av ett annat överlappande fönster eller popup-fönster. Att vara ägd placerar flera begränsningar i ett fönster.

• Ett ägt fönster är alltid ovanför ägaren i z-ordningen.
• Systemet förstör automatiskt ett ägt fönster när dess ägare förstörs.
• Ett ägt fönster döljs när dess ägare minimeras.

Endast ett överlappande fönster eller popup-fönster kan vara ett ägarfönster. ett underordnat fönster kan inte vara ett ägarfönster. Ett program skapar ett ägt fönster genom att ange ägarens fönsterhandtag som hwndParent parametern för CreateWindowEx när det skapar ett fönster med formatet WS_OVERLAPPED eller WS_POPUP. Parametern hwndParent måste identifiera ett överlappande fönster eller popup-fönster. Om hwndParent identifierar ett underordnat fönster tilldelar systemet ägarskap till det överordnade fönstret på den överordnade översta nivån i det underordnade fönstret. När du har skapat ett ägt fönster kan ett program inte överföra ägarskapet för fönstret till ett annat fönster.

Dialogrutor och meddelanderutor är ägda fönster som standard. Ett program anger ägarfönstret när du anropar en funktion som skapar en dialogruta eller meddelanderuta.

Ett program kan använda funktionen GetWindow med flaggan GW_OWNER för att hämta ett handtag till ett fönsters ägare.

Z-order

z-order- i ett fönster anger fönstrets position i en stack med överlappande fönster. Den här fönsterstacken är orienterad längs en imaginär axel, z-axeln, som sträcker sig utåt från skärmen. Fönstret överst i z-ordningen överlappar alla andra fönster. Fönstret längst ned i z-ordningen överlappas av alla andra fönster.

Systemet underhåller z-ordningen i en enda lista. Den lägger till fönster i z-ordningen baserat på om de är de översta fönstren, de översta fönstren eller underordnade fönstren. Ett översta fönstret överlappar alla andra icke-översta fönster, oavsett om det är aktivt eller förgrundsfönster. Ett fönster längst upp har formatet WS_EX_TOPMOST. Alla översta fönster visas i z-ordning före alla icke-översta fönster. Ett underordnat fönster grupperas med dess överordnade i z-ordning.

När ett program skapar ett fönster placerar systemet det överst i z-ordningen för fönster av samma typ. Du kan använda funktionen BringWindowToTop för att få ett fönster överst i z-ordningen för fönster av samma typ. Du kan ordna om z-ordningen med hjälp av funktionerna SetWindowPos och DeferWindowPos.

Användaren ändrar z-ordningen genom att aktivera ett annat fönster. Systemet placerar det aktiva fönstret överst i z-ordningen för fönster av samma typ. När ett fönster kommer överst i z-ordning, så gör även dess underordnade fönster. Du kan använda funktionen GetTopWindow för att söka i alla underordnade fönster i ett överordnat fönster och returnera ett handtag till det underordnade fönstret som är högst i z-ordning. Funktionen GetNextWindow hämtar ett handtag till nästa eller föregående fönster i z-ordning.

Visa tillstånd för fönster

Vid en viss tidpunkt kan ett fönster vara aktivt eller inaktivt. dold eller synlig; minimeras, maximeras eller återställs. Dessa egenskaper kallas kollektivt för -fönstret visar tillståndet. I följande avsnitt beskrivs fönstrets visningstillstånd:

• aktivt fönster
• Inaktiverad Windows-
• fönstersynlighet
• Minimerad, Maximerad och Återställd Windows-

Aktivt fönster

Ett aktivt fönster är det översta fönstret i programmet som användaren arbetar med. För att användaren enkelt ska kunna identifiera det aktiva fönstret placerar systemet det överst i z-ordningen och ändrar färgen på namnlisten och kantlinjen till de systemdefinierade aktiva fönsterfärgerna. Endast ett fönster på den översta nivån kan vara ett aktivt fönster. När användaren arbetar med ett underordnat fönster aktiverar systemet det överordnade fönstret på den översta nivån som är associerat med det underordnade fönstret.

Endast ett fönster på den översta nivån i systemet är aktivt i taget. Användaren aktiverar ett fönster på den översta nivån genom att klicka på det (eller ett av dess underordnade fönster) eller genom att använda tangentkombinationen ALT+ESC eller ALT+TAB. Ett program aktiverar ett fönster på den översta nivån genom att anropa funktionen SetActiveWindow. Andra funktioner kan göra så att systemet aktiverar ett annat fönster på den översta nivån, till exempel SetWindowPos, DeferWindowPos, SetWindowPlacementoch DestroyWindow. Även om ett program kan aktivera ett annat fönster på den översta nivån när som helst, bör det bara göra det som svar på en användaråtgärd för att undvika att förvirra användaren. Ett program använder funktionen GetActiveWindow för att hämta ett handtag till det aktiva fönstret.

När aktiveringen ändras från ett fönster på den översta nivån i ett program till den översta nivån i ett annat, skickar systemet ett WM_ACTIVATEAPP meddelande till båda programmen och meddelar dem om ändringen. När aktiveringen ändras till ett annat fönster på den översta nivån i samma program skickar systemet båda fönstren ett WM_ACTIVATE meddelande.

Inaktiverad Windows

Ett fönster kan inaktiveras. Ett inaktiverat fönster inte tar emot några tangentbords- eller musindata från användaren, men det kan ta emot meddelanden från andra fönster, från andra program och från systemet. Ett program inaktiverar vanligtvis ett fönster för att förhindra att användaren använder fönstret. Ett program kan till exempel inaktivera en push-knapp i en dialogruta för att förhindra att användaren väljer den. Ett program kan när som helst aktivera ett inaktiverat fönster. Om du aktiverar ett fönster återställs normala indata.

Som standard aktiveras ett fönster när det skapas. Ett program kan dock ange WS_DISABLED formatmall för att inaktivera ett nytt fönster. Ett program aktiverar eller inaktiverar ett befintligt fönster med hjälp av funktionen EnableWindow. Systemet skickar ett WM_ENABLE meddelande till ett fönster när dess aktiverade tillstånd håller på att ändras. Ett program kan avgöra om ett fönster är aktiverat med hjälp av funktionen IsWindowEnabled.

När ett underordnat fönster är inaktiverat skickar systemet det underordnade musinmatningsmeddelandena till det överordnade fönstret. Den överordnade använder meddelandena för att avgöra om det underordnade fönstret ska aktiveras. Mer information finns i Mouse Input.

Endast ett fönster i taget kan ta emot tangentbordsindata. att fönstret sägs ha tangentbordet fokus. Om ett program använder funktionen EnableWindow för att inaktivera ett tangentbordsfokusfönster förlorar fönstret tangentbordsfokus förutom att det inaktiveras. EnableWindow ställer sedan in tangentbordsfokus på NULL-, vilket innebär att inget fönster har fokus. Om ett underordnat fönster eller ett annat underordnat fönster har tangentbordsfokus förlorar det underordnade fönstret fokus när det överordnade fönstret är inaktiverat. Mer information finns i tangentbordsindata.

Synlighet för fönster

Ett fönster kan vara synligt eller dolt. Systemet visar ett synligt fönster på skärmen. Det döljer ett dolt fönster genom att inte rita det. Om ett fönster visas kan användaren ange indata till fönstret och visa fönstrets utdata. Om ett fönster är dolt inaktiveras det effektivt. Ett dolt fönster kan bearbeta meddelanden från systemet eller från andra fönster, men det kan inte bearbeta indata från användaren eller visa utdata. Ett program anger ett fönsters synlighetstillstånd när fönstret skapas. Senare kan programmet ändra synlighetstillståndet.

Ett fönster visas när WS_VISIBLE formatmall har angetts för fönstret. Som standard skapar funktionen CreateWindowEx ett dolt fönster om inte programmet anger WS_VISIBLE formatmall. Vanligtvis anger ett program WS_VISIBLE formatmall när det har skapat ett fönster för att hålla information om skapandeprocessen dold för användaren. Ett program kan till exempel hålla ett nytt fönster dolt medan det anpassar fönstrets utseende. Om formatmallen WS_VISIBLE anges i CreateWindowExskickar systemet WM_SHOWWINDOW-meddelandet till fönstret när fönstret har skapats, men innan det visas.

Ett program kan avgöra om ett fönster visas med hjälp av funktionen IsWindowVisible. Ett program kan visa (göra synligt) eller dölja ett fönster med hjälp av funktionen ShowWindow, SetWindowPos, DeferWindowPoseller SetWindowPlacement eller SetWindowLong. Dessa funktioner visar eller döljer ett fönster genom att ange eller ta bort WS_VISIBLE formatmallen för fönstret. De skickar också meddelandet WM_SHOWWINDOW till fönstret innan det visas eller döljs.

När ett ägarfönster minimeras döljer systemet automatiskt de associerade ägda fönstren. På samma sätt visar systemet automatiskt de associerade ägda fönstren när ett ägarfönster återställs. I båda fallen skickar systemet WM_SHOWWINDOW meddelandet till de ägda fönstren innan de döljs eller visas. Ibland kan ett program behöva dölja de ägda fönstren utan att behöva minimera eller dölja ägaren. I det här fallet använder programmet funktionen ShowOwnedPopups. Den här funktionen anger eller tar bort formatmallen WS_VISIBLE för alla ägda fönster och skickar meddelandet WM_SHOWWINDOW till de ägda fönstren innan de döljs eller visas. Att dölja ett ägarfönster påverkar inte synlighetstillståndet för de ägda fönstren.

När ett överordnat fönster visas visas även tillhörande underordnade fönster. På samma sätt, när det överordnade fönstret är dolt, är dess underordnade fönster också dolda. Att minimera det överordnade fönstret har ingen effekt på de underordnade fönstrens synlighetstillstånd. det vill: de underordnade fönstren minimeras tillsammans med den överordnade, men WS_VISIBLE formatmallen ändras inte.

Även om ett fönster har formatet WS_VISIBLE kanske användaren inte kan se fönstret på skärmen. andra fönster kan helt överlappa den eller så kan den ha flyttats utanför skärmens kant. Dessutom omfattas ett synligt underordnat fönster av de urklippsregler som har upprättats av relationen mellan överordnad och underordnad. Om fönstrets överordnade fönster inte visas visas det inte heller. Om det överordnade fönstret flyttas utanför skärmens kant flyttas även det underordnade fönstret eftersom ett underordnat fönster ritas i förhållande till den överordnades övre vänstra hörn. En användare kan till exempel flytta det överordnade fönstret som innehåller det underordnade fönstret tillräckligt långt från kanten av skärmen så att användaren kanske inte kan se det underordnade fönstret, även om det underordnade fönstret och dess överordnade fönster båda har WS_VISIBLE stil.

Minimerade, maximerade och återställde Windows

Ett maximerat fönster är ett fönster med WS_MAXIMIZE formatmall. Som standard förstorar systemet ett maximerat fönster så att det fyller skärmen eller, om det gäller ett underordnat fönster, det överordnade fönstrets klientområde. Även om ett fönsters storlek kan anges till samma storlek som ett maximerat fönster, är ett maximerat fönster något annorlunda. Systemet flyttar automatiskt fönstrets namnlist överst på skärmen eller längst upp i det överordnade fönstrets klientområde. Dessutom inaktiverar systemet fönstrets storleksgräns och funktionen för fönsterpositionering i namnlisten (så att användaren inte kan flytta fönstret genom att dra i namnlisten).

Ett minimerat fönster är ett fönster med WS_MINIMIZE formatmall. Som standard minskar systemet ett minimerat fönster till storleken på aktivitetsfältets knapp och flyttar det minimerade fönstret till aktivitetsfältet. Ett återställt fönster är ett fönster som har returnerats till sin tidigare storlek och position, det vill ex. den storlek det var innan det minimerades eller maximerades.

Om ett program anger formatmallen WS_MAXIMIZE eller WS_MINIMIZE i funktionen CreateWindowEx maximeras eller minimeras fönstret från början. När du har skapat ett fönster kan ett program använda funktionen CloseWindow för att minimera fönstret. Funktionen ArrangeIconicWindows ordnar ikonerna på skrivbordet, eller så ordnas ett överordnat fönsters minimerade underordnade fönster i det överordnade fönstret. Funktionen OpenIcon återställer ett minimerat fönster till dess tidigare storlek och position.

Funktionen ShowWindow kan minimera, maximera eller återställa ett fönster. Den kan också ange fönstrets synlighets- och aktiveringstillstånd. Funktionen SetWindowPlacement innehåller samma funktioner som ShowWindow, men den kan åsidosätta fönstrets standard minimerade, maximerade och återställde positioner.

Funktionerna IsZoomed och IsIconic avgör om ett visst fönster maximeras eller minimeras. Funktionen GetWindowPlacement hämtar de minimerade, maximerade och återställde positionerna för fönstret och avgör även fönstrets visningstillstånd.

När systemet tar emot ett kommando för att maximera eller återställa ett minimerat fönster skickar det ett WM_QUERYOPEN meddelande till fönstret. Om fönsterproceduren returnerar FALSE-ignorerar systemet kommandot maximera eller återställa.

Systemet anger automatiskt storleken och positionen för ett maximerat fönster till de systemdefinierade standardvärdena för ett maximerat fönster. Om du vill åsidosätta dessa standardvärden kan ett program antingen anropa funktionen SetWindowPlacement eller bearbeta det WM_GETMINMAXINFO meddelande som tas emot av ett fönster när systemet är på väg att maximera fönstret. WM_GETMINMAXINFO innehåller en pekare till en MINMAXINFO struktur som innehåller värden som systemet använder för att ange maximerad storlek och position. Om du ersätter dessa värden åsidosätts standardvärdena.

Fönsterstorlek och position

Ett fönsters storlek och position uttrycks som en avgränsningsrektangel som anges i koordinater i förhållande till skärmen eller det överordnade fönstret. Koordinaterna för ett fönster på den översta nivån är relativa till det övre vänstra hörnet på skärmen. koordinaterna för ett underordnat fönster är relativa till det övre vänstra hörnet i det överordnade fönstret. Ett program anger ett fönsters initiala storlek och position när fönstret skapas, men det kan när som helst ändra fönstrets storlek och position. Mer information finns i fyllda former.

Det här avsnittet innehåller följande avsnitt:

• standardstorlek och position
• spårningsstorlek
• systemkommandon
• storleks- och placeringsfunktioner
• storleks- och placeringsmeddelanden

Standardstorlek och position

Ett program kan göra det möjligt för systemet att beräkna den ursprungliga storleken eller positionen för ett fönster på den översta nivån genom att ange CW_USEDEFAULT i CreateWindowEx. Om programmet anger fönstrets koordinater till CW_USEDEFAULT och inte har skapat några andra fönster på den översta nivån, anger systemet det nya fönstrets position i förhållande till det övre vänstra hörnet på skärmen. Annars anger den positionen i förhållande till positionen för det översta fönstret som programmet skapade senast. Om parametrarna för bredd och höjd är inställda på CW_USEDEFAULT beräknar systemet storleken på det nya fönstret. Om programmet har skapat andra fönster på den översta nivån baserar systemet storleken på det nya fönstret på storleken på programmets senast skapade toppnivåfönster. Om du anger CW_USEDEFAULT när du skapar ett underordnat fönster eller popup-fönster kan systemet ange fönstrets storlek till den minsta standardstorleken för fönstret.

Spårningsstorlek

Systemet har en minsta och högsta spårningsstorlek för ett fönster i WS_THICKFRAME format. ett fönster med det här formatet har en storlekskantlinje. Den minsta spårningsstorleken är den minsta fönsterstorlek som du kan skapa genom att dra fönstrets storleksgräns. På samma sätt är maximal spårningsstorlek den största fönsterstorleken du kan skapa genom att dra storleksgränsen.

Ett fönsters minsta och högsta spårningsstorlekar är inställda på systemdefinierade standardvärden när systemet skapar fönstret. Ett program kan identifiera standardvärdena och åsidosätta dem genom att bearbeta WM_GETMINMAXINFO meddelandet. Mer information finns i Storlek och Placera meddelanden.

Systemkommandon

Ett program som har en fönstermeny kan ändra fönstrets storlek och position genom att skicka systemkommandon. Systemkommandon genereras när användaren väljer kommandon från fönstermenyn. Ett program kan emulera användaråtgärden genom att skicka ett WM_SYSCOMMAND meddelande till fönstret. Följande systemkommandon påverkar storleken och positionen för ett fönster.

Befallning	Beskrivning
SC_CLOSE	Stänger fönstret. Det här kommandot skickar ett WM_CLOSE meddelande till fönstret. Fönstret utför alla steg som behövs för att städa upp och förstöra sig själv.
SC_MAXIMIZE	Maximerar fönstret.
SC_MINIMIZE	Minimerar fönstret.
SC_MOVE	Flyttar fönstret.
SC_RESTORE	Återställer ett minimerat eller maximerat fönster till sin tidigare storlek och position.
SC_SIZE	Startar ett storlekskommando. Om du vill ändra storleken på fönstret använder du musen eller tangentbordet.

 

Storleks- och positionsfunktioner

När du har skapat ett fönster kan ett program ange fönstrets storlek eller position genom att anropa en av flera olika funktioner, inklusive SetWindowPlacement, MoveWindow, SetWindowPosoch DeferWindowPos. SetWindowPlacement anger ett fönsters minimerade position, maximerad position, återställd storlek och position samt visningstillstånd. Funktionerna MoveWindow och SetWindowPos är liknande. båda anger storleken eller positionen för ett enda programfönster. Funktionen SetWindowPos innehåller en uppsättning flaggor som påverkar fönstrets visningstillstånd. MoveWindow innehåller inte dessa flaggor. Använd BeginDeferWindowPos, DeferWindowPosoch EndDeferWindowPos funktioner för att samtidigt ange positionen för ett antal fönster, inklusive storlek, position, position i z-ordning och visningstillstånd.

Ett program kan hämta koordinaterna för ett fönsters avgränsningsrektangel med hjälp av funktionen GetWindowRect. GetWindowRect fyller en RECT- struktur med koordinaterna för fönstrets övre vänstra och nedre högra hörn. Koordinaterna är relativa till det övre vänstra hörnet på skärmen, även för ett underordnat fönster. Funktionen ScreenToClient eller MapWindowPoints mappar skärmkoordinaterna för ett underordnat fönsters avgränsningsrektangel till koordinater i förhållande till det överordnade fönstrets klientområde.

Funktionen GetClientRect hämtar koordinaterna för ett fönsters klientområde. GetClientRect fyller en RECT- struktur med koordinaterna för klientområdets övre vänstra och nedre högra hörn, men koordinaterna är relativa till själva klientområdet. Det innebär att koordinaterna för ett klientområdes övre vänstra hörn alltid är (0,0) och koordinaterna i det nedre högra hörnet är bredden och höjden på klientområdet.

Funktionen CascadeWindows överlappar fönstren på skrivbordet eller överlappar de underordnade fönstren i det angivna överordnade fönstret. Funktionen TileWindows paneler fönstren på skrivbordet eller paneler de underordnade fönstren i det angivna överordnade fönstret.

Storleks- och positionsmeddelanden

Systemet skickar meddelandet WM_GETMINMAXINFO till ett fönster vars storlek eller position håller på att ändras. Meddelandet skickas till exempel när användaren klickar på Flytta eller Storlek från fönstermenyn eller klickar på storlekslisten eller namnlisten. meddelandet skickas också när ett program anropar SetWindowPos för att flytta eller ändra storlek på fönstret. WM_GETMINMAXINFO innehåller en pekare till en MINMAXINFO- struktur som innehåller standard maximerad storlek och position för fönstret, samt standardstorlekarna för minsta och högsta spårning. Ett program kan åsidosätta standardvärdena genom att bearbeta WM_GETMINMAXINFO och ange lämpliga medlemmar i MINMAXINFO. Ett fönster måste ha formatet WS_THICKFRAME eller WS_CAPTION för att ta emot WM_GETMINMAXINFO. Ett fönster med formatmallen WS_THICKFRAME tar emot det här meddelandet under processen för att skapa fönster, samt när det flyttas eller storleksanpassas.

Systemet skickar meddelandet WM_WINDOWPOSCHANGING till ett fönster vars storlek, position, position i z-ordningen eller visningstillståndet håller på att ändras. Det här meddelandet innehåller en pekare till en WINDOWPOS- struktur som anger fönstrets nya storlek, position, position i z-ordning och visningstillstånd. Genom att ange medlemmar i WINDOWPOSkan ett program påverka fönstrets nya storlek, position och utseende.

När du har ändrat ett fönsters storlek, position, position i z-ordningen eller visningstillståndet skickar systemet WM_WINDOWPOSCHANGED meddelandet till fönstret. Det här meddelandet innehåller en pekare till WINDOWPOS- som informerar fönstret om dess nya storlek, position, position i z-ordningen och visningstillstånd. Att ange medlemmar i WINDOWPOS struktur som skickas med WM_WINDOWPOSCHANGED har ingen effekt på fönstret. Ett fönster som måste bearbeta WM_SIZE och WM_MOVE meddelanden måste skicka WM_WINDOWPOSCHANGED till funktionen DefWindowProc. annars skickar systemet inte WM_SIZE och WM_MOVE meddelanden till fönstret.

Systemet skickar meddelandet WM_NCCALCSIZE till ett fönster när fönstret skapas eller storleksanpassas. Systemet använder meddelandet för att beräkna storleken på ett fönsters klientområde och positionen för klientområdet i förhållande till fönstrets övre vänstra hörn. Ett fönster skickar vanligtvis det här meddelandet till standardfönstrets procedur. Det här meddelandet kan dock vara användbart i program som anpassar ett fönsters icke-tillfälliga område eller bevarar delar av klientområdet när fönstret är storleksanpassat. Mer information finns i Målning och ritning.

Fönsteranimering

Du kan skapa specialeffekter när du visar eller döljer fönster med hjälp av funktionen AnimateWindow. När fönstret animeras på det här sättet kommer systemet antingen att rulla, dra eller tona ned fönstret, beroende på de flaggor du anger i ett anrop till AnimateWindow.

Som standard använder systemet roll-animering. Med den här effekten verkar fönstret rulla upp (visar fönstret) eller rulla stängt (dölja fönstret). Du kan använda parametern dwFlags för att ange om fönstret ska rulla vågrätt, lodrätt eller diagonalt.

När du anger flaggan AW_SLIDE använder systemet bildanimering. Med den här effekten visas fönstret för att glida in i vyn (visar fönstret) eller glida ut ur vyn (dölja fönstret). Du kan använda parametern dwFlags för att ange om fönstret ska glida vågrätt, lodrätt eller diagonalt.

När du anger flaggan AW_BLEND använder systemet en alfablandad toning.

Du kan också använda flaggan AW_CENTER för att få ett fönster att se ut att kollapsa inåt eller expandera utåt.

Fönsterlayout och spegling

Fönsterlayouten definierar hur text- och GDI-objekt (Windows Graphics Device Interface) anges i ett fönster eller en enhetskontext (DC). Vissa språk, till exempel engelska, franska och tyska, kräver en layout från vänster till höger (LTR). Andra språk, till exempel arabiska och hebreiska, kräver layout från höger till vänster (RTL). Fönsterlayouten gäller för text men påverkar även andra GDI-element i fönstret, inklusive bitmappar, ikoner, ursprungets plats, knappar, sammanhängande trädkontroller och om den vågräta koordinaten ökar när du går åt vänster eller höger. När ett program till exempel har angett RTL-layout placeras ursprunget till höger i fönstret eller enheten och talet som representerar den vågräta koordinaten ökar när du flyttar vänster. Alla objekt påverkas dock inte av layouten för ett fönster. Till exempel måste layouten för dialogrutor, meddelanderutor och enhetskontexter som inte är associerade med ett fönster, till exempel metafil och skrivar-DC:er, hanteras separat. Detaljer för dessa nämns senare i det här avsnittet.

Med fönsterfunktionerna kan du ange eller ändra fönsterlayouten i arabiska och hebreiska versioner av Windows. Observera att det inte går att ändra till en RTL-layout (kallas även spegling) för fönster som har formatmallen CS_OWNDC eller för en domänkontrollant med GM_ADVANCED grafiskt läge.

Som standard är fönsterlayouten vänster till höger (LTR). Om du vill ange RTL-fönsterlayouten anropar du CreateWindowEx med formatet WS_EX_LAYOUTRTL. Som standard har ett underordnat fönster (det vill säga ett som skapats med WS_CHILD-format och med en giltig överordnad hWnd parameter i anropet till CreateWindow eller CreateWindowEx) samma layout som den överordnade. Om du vill inaktivera arv av spegling till alla underordnade fönster anger du WS_EX_NOINHERITLAYOUT i anropet till CreateWindowEx. Observera att spegling inte ärvs av ägda fönster (de som skapats utan formatmallen WS_CHILD) eller de som skapats med parametern parent hWnd i CreateWindowEx inställd på NULL-. Om du vill inaktivera arv av spegling för ett enskilt fönster bearbetar du det WM_NCCREATE meddelandet med GetWindowLong och SetWindowLong för att inaktivera flaggan WS_EX_LAYOUTRTL. Den här bearbetningen är utöver den andra bearbetningen som behövs. Följande kodfragment visar hur detta görs.

SetWindowLong (hWnd, 
               GWL_EXSTYLE, 
               GetWindowLong(hWnd,GWL_EXSTYLE) & ~WS_EX_LAYOUTRTL))

Du kan ange standardlayouten till RTL genom att anropa SetProcessDefaultLayout(LAYOUT_RTL). Alla fönster som skapas efter anropet speglas, men befintliga fönster påverkas inte. Om du vill inaktivera standardspegling anropar du SetProcessDefaultLayout(0).

Observera att SetProcessDefaultLayout endast speglar domänkontrollanterna i speglade fönster. Om du vill spegla en domänkontrollant anropar du SetLayout(hdc, LAYOUT_RTL). Mer information finns i diskussionen om att spegla enhetskontexter som inte är associerade med fönster, vilket kommer senare i det här avsnittet.

Bitmappar och ikoner i ett speglat fönster speglas också som standard. Alla dessa bör dock inte speglas. Till exempel bör de med text, en företagslogotyp eller en analog klocka inte speglas. Om du vill inaktivera spegling av bitmappar anropar du SetLayout- med den LAYOUT_BITMAPORIENTATIONPRESERVED biten i dwLayout. Om du vill inaktivera spegling i en domänkontrollant anropar du SetLayout(hdc, 0).

Om du vill fråga den aktuella standardlayouten anropar du GetProcessDefaultLayout. Vid en lyckad retur innehåller pdwDefaultLayout LAYOUT_RTL eller 0. Om du vill fråga layoutinställningarna för enhetskontexten anropar du GetLayout. Vid en lyckad retur returnerar GetLayout en DWORD- som anger layoutinställningarna enligt inställningarna för LAYOUT_RTL och LAYOUT_BITMAPORIENTATIONPRESERVED bitar.

När ett fönster har skapats ändrar du layouten med hjälp av funktionen SetWindowLong. Detta är till exempel nödvändigt när användaren ändrar användargränssnittsspråket i ett befintligt fönster från arabiska eller hebreiska till tyska. Men när du ändrar layouten för ett befintligt fönster måste du ogiltigförklara och uppdatera fönstret för att säkerställa att innehållet i fönstret ritas på samma layout. Följande kodexempel är från exempelkoden som ändrar fönsterlayouten efter behov:

// Using ANSI versions of GetWindowLong and SetWindowLong because Unicode
// is not needed for these calls

lExStyles = GetWindowLongA(hWnd, GWL_EXSTYLE);

// Check whether new layout is opposite the current layout
if (!!(pLState -> IsRTLLayout) != !!(lExStyles & WS_EX_LAYOUTRTL))
{
    // the following lines will update the window layout

    lExStyles ^= WS_EX_LAYOUTRTL;        // toggle layout
    SetWindowLongA(hWnd, GWL_EXSTYLE, lExStyles);
    InvalidateRect(hWnd, NULL, TRUE);    // to update layout in the client area
}

I spegling bör du tänka i termer av "nära" och "långt" i stället för "vänster" och "höger". Om du inte gör det kan det orsaka problem. En vanlig kodningspraxis som orsakar problem i ett speglat fönster uppstår vid mappning mellan skärmkoordinater och klientkoordinater. Till exempel använder program ofta kod som liknar följande för att placera en kontroll i ett fönster:

// DO NOT USE THIS IF APPLICATION MIRRORS THE WINDOW

// get coordinates of the window in screen coordinates
GetWindowRect(hControl, (LPRECT) &rControlRect);  

// map screen coordinates to client coordinates in dialog
ScreenToClient(hDialog, (LPPOINT) &rControlRect.left); 
ScreenToClient(hDialog, (LPPOINT) &rControlRect.right);

Detta orsakar problem med spegling eftersom rektangelns vänstra kant blir högerkant i ett speglat fönster och vice versa. Undvik det här problemet genom att ersätta ScreenToClient-anrop med ett anrop till MapWindowPoints enligt följande:

// USE THIS FOR MIRRORING

GetWindowRect(hControl, (LPRECT) &rControlRect);
MapWindowPoints(NULL, hDialog, (LPPOINT) &rControlRect, 2)

Den här koden fungerar eftersom MapWindowPoints ändras för att växla koordinaterna till vänster och höger när klientfönstret speglas på plattformar som stöder spegling. Mer information finns i avsnittet Anmärkningar i MapWindowPoints.

En annan vanlig metod som kan orsaka problem i speglade fönster är att placera objekt i ett klientfönster med förskjutningar i skärmkoordinater i stället för klientkoordinater. I följande kod används till exempel skillnaden i skärmkoordinater som x-positionen i klientkoordinaterna för att placera en kontroll i en dialogruta.

// OK if LTR layout and mapping mode of client is MM_TEXT,
// but WRONG for a mirrored dialog 

RECT rdDialog;
RECT rcControl;

HWND hControl = GetDlgItem(hDlg, IDD_CONTROL);
GetWindowRect(hDlg, &rcDialog);             // gets rect in screen coordinates
GetWindowRect(hControl, &rcControl);
MoveWindow(hControl,
           rcControl.left - rcDialog.left,  // uses x position in client coords
           rcControl.top - rcDialog.top,
           nWidth,
           nHeight,
           FALSE);

Den här koden fungerar bra när dialogrutan har layout från vänster till höger (LTR) och mappningsläget för klienten är MM_TEXT eftersom den nya x-positionen i klientkoordinaterna motsvarar skillnaden i kontrollens vänstra kanter och dialogrutan i skärmkoordinater. Men i en speglad dialogruta är vänster och höger omvända, så i stället bör du använda MapWindowPoints på följande sätt:

RECT rcDialog;
RECT rcControl;

HWND hControl - GetDlgItem(hDlg, IDD_CONTROL);
GetWindowRect(hControl, &rcControl);

// MapWindowPoints works correctly in both mirrored and non-mirrored windows.
MapWindowPoints(NULL, hDlg, (LPPOINT) &rcControl, 2);

// Now rcControl is in client coordinates.
MoveWindow(hControl, rcControl.left, rcControl.top, nWidth, nHeight, FALSE)

Speglingsdialogrutor och meddelanderutor

Dialogrutor och meddelanderutor ärver inte layouten, så du måste ange layouten explicit. Om du vill spegla en meddelanderuta anropar du MessageBox eller MessageBoxEx med alternativet MB_RTLREADING. Om du vill layoutera en dialogruta från höger till vänster använder du den utökade formatmallen WS_EX_LAYOUTRTL i dialogrutans mallstruktur DLGTEMPLATEEX. Egenskapsblad är ett specialfall med dialogrutor. Varje flik behandlas som en separat dialogruta, så du måste ta med WS_EX_LAYOUTRTL formatmall på varje flik som du vill spegla.

Spegling av enhetskontexter som inte är associerade med ett fönster

Domänkontrollanter som inte är associerade med ett fönster, till exempel metafil eller skrivar-DCs, ärver inte layouten, så du måste ange layouten explicit. Om du vill ändra layouten för enhetskontexten använder du funktionen SetLayout.

Funktionen SetLayout används sällan med windows. Normalt får windows endast en associerad domänkontrollant vid bearbetning av ett WM_PAINT meddelande. Ibland skapar ett program en domänkontrollant för ett fönster genom att anropa GetDC-. Hur som helst anges den första layouten för domänkontrollanten av BeginPaint eller GetDC enligt fönstrets WS_EX_LAYOUTRTL flagga.

Värdena som returneras av GetWindowOrgEx, GetWindowExtEx, GetViewportOrgEx och GetViewportExtEx påverkas inte av att anropa SetLayout.

När layouten är RTL returnerar GetMapMode MM_ANISOTROPIC i stället för MM_TEXT. Anropar SetMapMode med MM_TEXT fungerar korrekt. endast returvärdet från GetMapMode påverkas. Att anropa SetLayout(hdc, LAYOUT_RTL) när mappningsläget är MM_TEXT gör att det rapporterade mappningsläget ändras till MM_ANISOTROPIC.

Fönsterförstörelse

I allmänhet måste ett program förstöra alla fönster som skapas. Det gör den med hjälp av funktionen DestroyWindow. När ett fönster förstörs döljer systemet fönstret, om det är synligt, och tar sedan bort eventuella interna data som är associerade med fönstret. Detta ogiltigförklarar fönsterhandtaget, som inte längre kan användas av programmet.

Ett program förstör många av de fönster som skapas strax efter att de har skapats. Ett program förstör till exempel vanligtvis ett dialogrutefönster så snart programmet har tillräckligt med indata från användaren för att fortsätta sin uppgift. Ett program förstör slutligen programmets huvudfönster (innan det avslutas).

Innan du förstör ett fönster bör ett program spara eller ta bort alla data som är associerade med fönstret, och det bör frigöra alla systemresurser som allokerats för fönstret. Om programmet inte släpper resurserna frigör systemet alla resurser som inte frigörs av programmet.

Att förstöra ett fönster påverkar inte den fönsterklass som fönstret skapas från. Nya fönster kan fortfarande skapas med den klassen, och alla befintliga fönster i den klassen fortsätter att fungera. Att förstöra ett fönster förstör också fönstrets underordnade fönster. Funktionen DestroyWindow skickar först ett WM_DESTROY meddelande till fönstret och sedan till dess underordnade fönster och underordnade fönster. På så sätt förstörs också alla underordnade fönster i fönstret som förstörs.

Ett fönster med en fönstermeny får ett WM_CLOSE meddelande när användaren klickar på Stäng. Genom att bearbeta det här meddelandet kan ett program be användaren om bekräftelse innan fönstret förstörs. Om användaren bekräftar att fönstret ska förstöras kan programmet anropa funktionen DestroyWindow för att förstöra fönstret.

Om fönstret som förstörs är det aktiva fönstret överförs både aktiva tillstånd och fokustillstånd till ett annat fönster. Fönstret som blir det aktiva fönstret är nästa fönster, enligt alt+ESC-tangentkombinationen. Det nya aktiva fönstret avgör sedan vilket fönster som tar emot tangentbordets fokus.