Översikt över teknikregioner
Om flera presentationstekniker används i ett program, till exempel WPF, Win32 eller DirectX, måste de dela renderingsområdena i ett gemensamt fönster på den översta nivån. Det här avsnittet beskriver problem som kan påverka presentationen och indata för ditt WPF-interoperationsprogram.
Regioner
I ett fönster på den översta nivån kan du konceptualisera att varje HWND som består av en av teknikerna i ett interoperationsprogram har en egen region (kallas även "luftrum"). Varje pixel i fönstret tillhör exakt en HWND, vilket utgör dess region. (Strikt sett finns det mer än en WPF-region om det finns mer än en WPF HWND, men i den här diskussionen kan du anta att det bara finns en). Regionen innebär att alla skikt eller andra fönster som försöker rendera ovanför den pixeln under programmets livslängd måste ingå i samma teknik på återgivningsnivå. Försök att återge WPF-pixlar över Win32 leder till oönskade resultat och är så mycket som möjligt förhindrat via interoperations-API:erna.
Region exempel
Följande bild visar ett program som blandar Win32, DirectX och WPF. Varje teknik använder sin egen separata, icke-överlappande uppsättning pixlar, och det finns inga regionproblem.
Anta att det här programmet använder muspekarpositionen för att skapa en animering som försöker återge över någon av dessa tre regioner. Oavsett vilken teknik som var ansvarig för själva animeringen skulle den tekniken inkräkta på de andra tvås områden. Följande bild visar ett försök att återge en WPF-cirkel över en Win32-region.
En annan överträdelse är om du försöker använda transparens eller alfablandning mellan olika tekniker. I följande bild bryter WPF-rutan mot Regionerna Win32 och DirectX. Eftersom pixlarna i WPF-rutan är halvtransparentera måste de ägas gemensamt av både DirectX och WPF, vilket inte är möjligt. Så detta är en annan överträdelse och kan inte byggas.
De föregående tre exemplen använde rektangulära regioner, men olika former är möjliga. En region kan till exempel ha ett hål. Följande bild visar en Win32-region med ett rektangulärt hål, vilket är storleken på WPF- och DirectX-regionerna tillsammans.
Regioner kan också vara helt icke-sektangulära, eller någon form som kan beskrivas av en Win32 HRGN (region).
Transparens och Top-Level-fönster
Fönsterhanteraren i Windows bearbetar bara Win32 HWNDs. Därför är varje Window i WPF en HWND. Det Window HWND måste följa de allmänna reglerna för alla HWND. Inom denna HWND kan WPF-kod göra vad de övergripande WPF-API:erna stöder. Men för interaktioner med andra HWND:er på skrivbordet måste WPF följa Win32-regler för bearbetning och återgivning. WPF stöder icke-rektangulära fönster med hjälp av Win32-API:er – HRGN:er för icke-rektangulära fönster och skiktade fönster för en alfa per bildpunkt.
Konstanta alfa- och färgnycklar stöds inte. Funktionerna i Win32-skiktade fönster varierar beroende på plattform.
Skiktade fönster kan göra hela fönstret genomskinligt (halvtransparent) genom att ange ett alfavärde som ska tillämpas på varje pixel i fönstret. (Win32 stöder faktiskt alfa per pixel, men det är mycket svårt att använda i praktiska program eftersom du i det här läget skulle behöva rita alla underordnade HWND själv, inklusive dialogrutor och listrutor).
WPF stöder HRGN; Det finns dock inga hanterade API:er för den här funktionen. Du kan använda plattformsanrop och HwndSource för att anropa relevanta Win32-API:er. För mer information, se Anropa inbyggda funktioner från "Managed Code".
WPF-skiktade fönster har olika funktioner på olika operativsystem. Detta beror på att WPF använder DirectX för att rendera, och skiktade fönster har främst utformats för GDI-återgivning, inte DirectX-återgivning.
WPF stöder maskinvaruaccelererade skiktade fönster.
WPF stöder inte transparensfärgnycklar eftersom WPF inte kan garantera att återge den exakta färgen du begärde, särskilt när renderingen är maskinvaruaccelererad.
För mer information om begränsningarna för interopområden, se HWND inuti WPF.
Se även
.NET Desktop feedback