Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
WPF och Windows Forms innehåller två olika arkitekturer för att skapa programgränssnitt. Namnområdet System.Windows.Forms.Integration innehåller klasser som möjliggör vanliga interoperationsscenarier. De två nyckelklasserna som implementerar interoperationsfunktioner är WindowsFormsHost och ElementHost. I det här avsnittet beskrivs vilka interoperationsscenarier som stöds och vilka scenarier som inte stöds.
Anmärkning
Särskild hänsyn tas till hybridkontrollscenariot . En hybridkontroll har en kontroll från en teknik kapslad i en kontroll från den andra tekniken. Detta kallas även för en kapslad interoperabilitet. En hybridkontroll på flera nivåer har mer än en nivå av hybridkontrollinbäddning. Ett exempel på en flernivå-kapslad samverkan är en Windows Forms-kontroll som innehåller en WPF-kontroll som i sin tur innehåller en annan Windows Forms-kontroll. Hybridkontroller med flera nivåer stöds inte.
Vara värd för Windows Forms-kontroller i WPF
Följande interoperationsscenarier stöds när en WPF-kontroll är värd för en Windows Forms-kontroll:
WPF-kontrollen kan vara värd för en eller flera Windows Forms-kontroller med XAML.
Den kan vara värd för en eller flera Windows Forms-kontroller med hjälp av kod.
Den kan vara värd för Windows Forms-containerkontroller som innehåller andra Windows Forms-kontroller.
Det kan innehålla ett huvud-/detaljformulär med en WPF-huvuddel och Windows Forms-detaljer.
Det kan hantera ett huvud-/detaljformulär med en Windows Forms-huvudkomponent och WPF-detaljer.
Den kan vara värd för en eller flera ActiveX-kontroller.
Den kan vara värd för en eller flera sammansatta kontroller.
Den kan vara värd för hybridkontroller med XAML (Extensible Application Markup Language).
Den kan hantera hybridkontroller med hjälp av kod.
Stöd för layout
I följande lista beskrivs kända begränsningar när WindowsFormsHost-elementet försöker integrera sin värdbaserade Windows Forms-kontroll i WPF-layoutsystemet.
I vissa fall går det inte att ändra storlek på Windows Forms-kontroller, eller så kan de bara storleksanpassas till specifika dimensioner. En Windows Forms-ComboBox-kontroll stöder till exempel bara en enda höjd, vilket definieras av kontrollens teckenstorlek. I en dynamisk WPF-layout, som förutsätter att elementen kan sträcka sig lodrätt, kommer en värdbaserad ComboBox kontroll inte att sträcka sig som förväntat.
Windows Forms-kontroller kan inte roteras eller skeva. När du till exempel roterar användargränssnittet med 90 grader kommer värdbaserade Windows Forms-kontroller att behålla sin upprättstående position.
I de flesta fall stöder Windows Forms-kontroller inte proportionell skalning. Kontrollens övergripande dimensioner skalas, men underordnade kontroller och komponentelement i kontrollen kanske inte ändrar storlek som förväntat. Den här begränsningen beror på hur väl varje Windows Forms-kontroll stöder skalning.
I ett WPF-användargränssnitt kan du ändra z-ordningen för element för att kontrollera överlappande beteende. En värdbaserad Windows Forms-kontroll ritas i en separat HWND, så den ritas alltid ovanpå WPF-element.
Windows Forms-kontroller stöder automatisk skalning baserat på teckenstorleken. Om du ändrar teckenstorleken i ett WPF-användargränssnitt ändras inte hela layouten, även om enskilda element kan ändra storlek dynamiskt.
Omgivande egenskaper
Vissa av omgivningsegenskaperna för WPF-kontroller har motsvarigheter i Windows Forms. Dessa omgivande egenskaper sprids till de värdbaserade Windows Forms-kontrollerna och exponeras som offentliga egenskaper på WindowsFormsHost kontrollen. Kontrollen WindowsFormsHost översätter varje WPF ambient-egenskap till motsvarande Windows Forms.
Mer information finns i Windows Forms and WPF Property Mapping.
Beteende
I följande tabell beskrivs interoperationsbeteende.
| Beteende | Understödd | Stöds inte |
|---|---|---|
| Genomskinlighet | Windows Forms-kontrollåtergivning stöder transparens. Bakgrunden till den överordnade WPF-kontrollen kan bli bakgrunden till värdbaserade Windows Forms-kontroller. | Vissa Windows Forms-kontroller stöder inte transparens. Kontrollerna och TextBox är till exempel ComboBox inte transparenta när de hanteras av WPF. |
| Tabbning | Tabbordningen för värdbaserade Windows Forms-kontroller är densamma som när kontrollerna finns i ett Windows Forms-baserat program. Tabbning från en WPF-kontroll till en Windows Forms-kontroll med TAB-tangenten och SKIFT+TAB-tangenterna fungerar som vanligt. Windows Forms-kontroller som har egenskapsvärdet TabStop false får inte fokus när användaren flikar igenom kontroller.– Varje WindowsFormsHost kontroll har ett TabIndex värde som avgör när kontrollen kommer att WindowsFormsHost få fokus. – Windows Forms-kontroller som finns i en WindowsFormsHost container följer den ordning som anges av TabIndex egenskapen. När man tabbar från det sista tabbindexet sätts fokus på nästa WPF-kontroll, om den finns. Om det inte finns någon annan fokuserbar WPF-kontroll återgår tabbning till den första Windows Forms-kontrollen i tabbordningen. - TabIndex -värden för kontroller i WindowsFormsHost är relativt samma Windows Forms-kontroller som finns i WindowsFormsHost kontrollen. - Tabbing respekterar kontrollspecifikt beteende. Om du till exempel trycker på TABB-tangenten i en TextBox kontroll som har ett AcceptsTab egenskapsvärde true anger du en flik i textrutan i stället för att flytta fokus. |
Ej tillämpbart. |
| Navigering med piltangenter | - Navigering med piltangenterna i WindowsFormsHost kontrollen är samma som i en vanlig Windows Forms-containerkontroll: Uppåtpilen och vänsterpilen väljer den tidigare kontrollen, och tangenterna NEDÅTPIL och HÖGERPIL väljer nästa kontroll. – Uppåtpilen och vänsterpilen från den första kontrollen som finns i WindowsFormsHost kontrollen utför samma åtgärd som kortkommandot SKIFT+TAB. Om det finns en fokuserbar WPF-kontroll flyttas fokus utanför WindowsFormsHost kontrollen. Det här beteendet skiljer sig från standardbeteendet ContainerControl eftersom ingen omslutning till den sista kontrollen sker. Om det inte finns någon annan fokuserbar WPF-kontroll återgår fokus till den sista Windows Forms-kontrollen i tabbordningen. – Nedåtpilen och högerpilen från den sista kontrollen som finns i WindowsFormsHost kontrollen utför samma åtgärd som TABB-tangenten. Om det finns en fokuserbar WPF-kontroll flyttas fokus utanför WindowsFormsHost kontrollen. Det här beteendet skiljer sig från standardbeteendet ContainerControl eftersom ingen omslutning till den första kontrollen sker. Om det inte finns någon annan fokuserbar WPF-kontroll återgår fokus till den första Windows Forms-kontrollen i tabbordningen. |
Ej tillämpbart. |
| Acceleratorer | Acceleratorer fungerar som vanligt, förutom där det anges i kolumnen "Stöds inte". | Dubblettacceleratorer mellan olika tekniker fungerar inte som vanliga dubblettacceleratorer. När en accelerator dupliceras mellan tekniker, med minst en på en Windows Forms-kontroll och den andra på en WPF-kontroll, tar Windows Forms-kontrollen alltid emot acceleratorn. Fokus växlar inte mellan kontrollerna när dubblettacceleratorn trycks in. |
| Snabbtangenter | Kortkommandon fungerar som vanligt, utom när det anges i kolumnen "Stöds inte". | – Kortkommandon för Windows Forms som hanteras i förbearbetningsfasen har alltid företräde framför WPF-genvägsnycklar. Om du till exempel har definierat en ToolStrip kontroll med CTRL+S-kortkommandon och ett WPF-kommando är bundet till CTRL+S ToolStrip , anropas alltid kontrollhanteraren först, oavsett fokus. – Kortkommandon för Windows Forms som hanteras av KeyDown händelsen bearbetas senast i WPF. Du kan förhindra det här beteendet genom att åsidosätta Windows Forms-kontrollens IsInputKey metod eller hantera PreviewKeyDown händelsen. Återvänd true från IsInputKey-metoden eller ange värdet för PreviewKeyDownEventArgs.IsInputKey-egenskapen till true i din PreviewKeyDown-händelsehanterare. |
| AcceptsReturn, AcceptsTab och annat kontrollspecifikt beteende | Egenskaper som ändrar standardbeteendet för tangentbordet fungerar som vanligt, förutsatt att Windows Forms-kontrollen åsidosätter IsInputKey metoden för att returnera true. |
Windows Forms-kontroller som ändrar standardbeteendet för tangentbordet genom att hantera KeyDown-händelsen bearbetas sist i WPF-värd-kontrollen. Eftersom dessa kontroller bearbetas sist kan de skapa ett oväntat beteende. |
| Inträdes- och utträdeshändelser | När fokus inte går till den innehållande ElementHost kontrollen, aktiveras händelserna Enter och Lämna som vanligt när fokus ändras inom en enda WindowsFormsHost kontroll. | Ange och Lämna händelser aktiveras inte när följande fokusändringar inträffar: - Från insidan till utsidan av en WindowsFormsHost kontroll. - Från utsidan till inuti en WindowsFormsHost kontroll. - Utanför en WindowsFormsHost kontroll. – Från en Windows Forms-kontroll som finns i en WindowsFormsHost kontroll till en ElementHost kontroll som finns i samma WindowsFormsHost. |
| Multitrådning | Alla sorter av multitråd stöds. | Både Windows Forms- och WPF-teknikerna förutsätter en enkeltrådad samtidighetsmodell. Under felsökningen skapar anrop till ramverksobjekt från andra trådar ett undantag för att framtvinga detta krav. |
| Säkerhet | Alla interoperationsscenarier kräver fullständigt förtroende. | Inga interoperationsscenarier tillåts i partiellt förtroende. |
| Tillgänglighet | Alla hjälpmedelsscenarier stöds. Hjälpmedelsprodukter fungerar korrekt när de används för hybridprogram som innehåller både Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
| Urklipp | Alla Urklippsåtgärder fungerar som vanligt. Detta omfattar att klippa och klistra in mellan Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
| Dra och släpp-funktion | Alla dra och släpp-åtgärder fungerar som vanligt. Detta omfattar åtgärder mellan Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
Användning av WPF-kontroller i Windows-formulär
Följande interoperationsscenarier stöds när en Windows Forms-kontroll är värd för en WPF-kontroll:
Hostar en eller flera WPF-kontroller med hjälp av kod.
Associera ett egenskapsblad med en eller flera värdbaserade WPF-kontroller.
Att vara värd för en eller flera WPF-sidor i ett formulär.
Startar ett WPF-fönster.
Skapa ett huvud-/detaljformulär med ett Windows Forms-huvud och WPF-detaljer.
Värdskap för ett master/detalj-formulär med en WPF-master och Windows Forms-detaljer.
Värd för anpassade WPF-kontroller.
Värdtjänst för hybridkontroller.
Omgivande egenskaper
Vissa av de omgivande egenskaperna för Windows Forms-kontroller har WPF-motsvarigheter. Dessa omgivande egenskaper sprids till de värdbaserade WPF-kontrollerna och exponeras som offentliga egenskaper på ElementHost kontrollen. Kontrollen ElementHost översätter varje omgivande Windows Forms-egenskap till dess WPF-motsvarighet.
Mer information finns i Windows Forms and WPF Property Mapping.
Beteende
I följande tabell beskrivs interoperationsbeteende.
| Beteende | Understödd | Stöds inte |
|---|---|---|
| Genomskinlighet | WPF-kontrollåtergivning stöder transparens. Bakgrunden för den överordnade Windows Forms-kontrollen kan bli bakgrunden till värdbaserade WPF-kontroller. | Ej tillämpbart. |
| Multitrådning | Alla sorter av multitråd stöds. | Både Windows Forms- och WPF-teknikerna förutsätter en enkeltrådad samtidighetsmodell. Under felsökningen skapar anrop till ramverksobjekt från andra trådar ett undantag för att framtvinga detta krav. |
| Säkerhet | Alla interoperationsscenarier kräver fullständigt förtroende. | Inga interoperationsscenarier tillåts i partiellt förtroende. |
| Tillgänglighet | Alla hjälpmedelsscenarier stöds. Hjälpmedelsprodukter fungerar korrekt när de används för hybridprogram som innehåller både Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
| Urklipp | Alla Urklippsåtgärder fungerar som vanligt. Detta omfattar att klippa och klistra in mellan Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
| Dra och släpp-funktion | Alla dra och släpp-åtgärder fungerar som vanligt. Detta omfattar åtgärder mellan Windows Forms- och WPF-kontroller. | Ej tillämpbart. |
Se även
.NET Desktop feedback