STRIKT efterlevnad
En del källkod som kompileras kan generera felmeddelanden när du aktiverar STRIKT typkontroll. I följande avsnitt beskrivs de minimala kraven för att få koden att kompileras när STRICT- är aktiverad. Ytterligare steg rekommenderas, särskilt för att skapa portabel kod.
Allmänna krav
Huvudkravet är att du måste deklarera rätt hanteringstyper och funktionspekare i stället för att förlita dig på mer allmänna typer. Du kan inte använda en referenstyp där en annan förväntas. Det innebär också att du kan behöva ändra funktionsdeklarationer och använda fler typgjutningar.
För bästa resultat bör den allmänna HANDLE- endast användas när det behövs.
Deklarera funktioner i ditt program
Kontrollera att alla programfunktioner har deklarerats. Att placera alla funktionsdeklarationer i en inkluderingsfil rekommenderas eftersom du enkelt kan skanna dina deklarationer och leta efter parameter- och returtyper som ska ändras.
Om du använder kompileringsalternativet /Zg för att skapa huvudfiler för dina funktioner ska du komma ihåg att du får olika resultat beroende på om du har aktiverat STRIKT typkontroll. Med STRIKT inaktiverad genererar alla hanteringstyper samma bastyp. Med STRIKT aktiverat genererar de olika bastyper. För att undvika konflikter måste du återskapa huvudfilen varje gång du aktiverar eller inaktiverar STRICT, eller redigerar rubrikfilen för att använda typerna HWND, HDC, HANDLEoch så vidare i stället för bastyperna.
Alla funktionsdeklarationer som du kopierade från Windows.h till källkoden kan ha ändrats och din lokala deklaration kan vara inaktuell. Ta bort din lokala deklaration.
Typer som kräver casts
Vissa funktioner har allmänna returtyper eller parametrar. Funktionen SendMessage returnerar till exempel data som kan vara valfritt antal typer, beroende på kontexten. När du ser någon av dessa funktioner i källkoden ska du se till att du använder rätt typgjutning och att den är så specifik som möjligt. Följande lista är ett exempel på dessa funktioner.
När du anropar SendMessage, DefWindowProceller SendDlgItemMessagebör du först skicka resultatet för att skriva UINT_PTR. Du måste vidta liknande åtgärder för alla funktioner som returnerar ett LRESULT- eller LONG_PTR värde, där resultatet innehåller ett handtag. Detta är nödvändigt för att skriva portabel kod eftersom storleken på ett handtag varierar beroende på vilken version av Windows. Casten (UINT_PTR) garanterar korrekt konvertering. Följande kod visar ett exempel där SendMessage- returnerar ett handtag till en pensel:
HBRUSH hbr;
hbr = (HBRUSH)(UINT_PTR)SendMessage(hwnd, WM_CTLCOLOR, ..., ...);
Parametern CreateWindow och CreateWindowExhmenu används ibland för att skicka ett heltalskontrollidentifierare (ID). I det här fallet måste du omvandla ID:t till en HMENU- typ:
HWND hwnd;
int id;
hwnd = CreateWindow(
TEXT("Button"), TEXT("OK"), BS_PUSHBUTTON,
x, y, cx, cy, hwndParent,
(HMENU)id, // Cast required here
hinst,
NULL);
Ytterligare överväganden
För att få ut mesta möjliga av STRIKT typkontroll finns det ytterligare riktlinjer som du bör följa. Koden blir mer portabel i framtida versioner av Windows om du gör följande ändringar.
Typerna WPARAM, LPARAM, LRESULToch LPVOID är polymorfa datatyper. De innehåller olika typer av data vid olika tidpunkter, även när STRIKT typkontroll är aktiverad. För att få nytta av typkontroll bör du omvandla värden för dessa typer så snart som möjligt. (Observera att meddelandeknäckare automatiskt omarbetas wParam och lParam åt dig på ett bärbart sätt.)
Var särskilt noga med att särskilja HMODULE- och HINSTANCE- typer. Även med STRIKT aktiverat definieras de som samma bastyp. De flesta hanteringsfunktioner för kernelmoduler använder HINSTANCE- typer, men det finns några funktioner som bara returnerar eller accepterar HMODULE- typer.
Relaterade ämnen