Megosztás a következőn keresztül:

WPF Add-Ins áttekintése

A .NET-keretrendszer tartalmaz egy bővítménymodellt, amellyel a fejlesztők olyan alkalmazásokat hozhatnak létre, amelyek támogatják a bővíthetőséget. Ez a bővítménymodell lehetővé teszi olyan bővítmények létrehozását, amelyek integrálhatók és bővítik az alkalmazás funkcióit. Bizonyos esetekben az alkalmazásoknak a bővítmények által biztosított felhasználói felületeket is meg kell jelenítenie. Ez a témakör bemutatja, hogyan bővíti a WPF a .NET-keretrendszer bővítménymodelljét, hogy lehetővé tegye ezeket a forgatókönyveket, a mögöttes architektúrát, annak előnyeit és korlátait.

Előfeltételek

A .NET-keretrendszer bővítménymodelljének ismerete szükséges. További információ: Bővítmények és bővíthetőség.

Add-Ins Áttekintés

Annak érdekében, hogy elkerüljük az alkalmazások újrafordításának és újbóli üzembe helyezésének összetettségét az új funkciók beépítése érdekében, az alkalmazások bővíthetőségi mechanizmusokat vezetnek be, amelyek lehetővé teszik a fejlesztők (mind az első, mind a harmadik fél) számára, hogy más, velük integrálható alkalmazásokat hozzanak létre. Az ilyen típusú bővíthetőség támogatásának leggyakoribb módja a bővítmények (más néven "bővítmények" és "beépülő modulok") használata. Példák olyan valós alkalmazásokra, amelyek bővíthetőséget fednek fel bővítményekkel:

  • Internet Explorer-bővítmények.

  • Windows Media Player beépülő modulok.

  • Visual Studio-bővítmények.

A Windows Media Player bővítménymodell például lehetővé teszi a külső fejlesztők számára, hogy olyan "beépülő modulokat" implementáljanak, amelyek többféleképpen bővítik a Windows Media Playert, például dekódereket és kódolókat hoznak létre olyan médiaformátumokhoz, amelyeket a Windows Media Player nem támogat natív módon (például DVD, MP3), hangeffektusokat és bőröket. Minden bővítménymodell úgy van kialakítva, hogy elérhetővé tegye az alkalmazás számára egyedi funkciókat, bár számos olyan entitás és viselkedés létezik, amelyek az összes bővítménymodellre jellemzőek.

A tipikus bővíthetőségi megoldások három fő entitása a szerződések, a bővítmények és a gazdagépalkalmazások. A szerződések kétféleképpen határozzák meg, hogyan integrálhatók a bővítmények a gazdagépalkalmazásokkal:

  • A bővítmények integrálhatók a gazdagépalkalmazások által implementált funkciókkal.

  • Az alkalmazások gazdaként funkcionálnak, és elérhetővé teszik a bővítmények integrációját.

A bővítmények használatához a gazdaalkalmazásoknak meg kell keresniük és be kell tölteniük őket futás közben. Következésképpen a bővítményeket támogató alkalmazások a következő további felelősségekkel rendelkeznek:

  • Felderítés: Olyan bővítmények keresése, amelyek megfelelnek a gazdagépalkalmazások által támogatott szerződéseknek.

  • Aktiválás: A bővítményekkel való kommunikáció betöltése, futtatása és létrehozása.

  • Elkülönítés: Alkalmazástartományok vagy folyamatok használata olyan elkülönítési határok létrehozására, amelyek megvédik az alkalmazásokat a bővítményekkel kapcsolatos esetleges biztonsági és végrehajtási problémáktól.

  • Kommunikáció: Lehetővé teszi a bővítmények és a gazdagépalkalmazások számára, hogy a metódusok meghívásával és az adatok továbbításával kommunikáljanak egymással az elkülönítési határok között.

  • Élettartam-kezelés: Az alkalmazástartományok és folyamatok betöltése és eltávolítása tiszta, kiszámítható módon (lásd : Application Domains).

  • Verziószámozás: Annak biztosítása, hogy a gazdagépalkalmazások és -bővítmények továbbra is kommunikálhassanak az új verziók létrehozásakor.

Végső soron egy robusztus bővítménymodell fejlesztése nem triviális vállalkozás. Ezért a .NET-keretrendszer egy infrastruktúrát biztosít a bővítménymodellek létrehozásához.

Megjegyzés:

A bővítményekkel kapcsolatos részletesebb információkért lásd a bővítményeket és a bővíthetőséget.

.NET-keretrendszer Add-In modell áttekintése

A névtérben System.AddIn található .NET-keretrendszer bővítménymodell olyan típusokat tartalmaz, amelyek célja a bővítmények bővíthetőségének egyszerűsítése. A .NET-keretrendszer bővítménymodelljének alapvető egysége a szerződés, amely meghatározza, hogyan kommunikál egy gazdagépalkalmazás és egy bővítmény egymással. A szerződés elérhető egy gazdagépalkalmazás számára, egy gazdagépalkalmazásra specifikus nézet segítségével. Hasonlóképpen, a szerződés bővítményspecifikus nézete is elérhető a bővítmény számára. Az adapterek lehetővé teszik, hogy egy gazdaalkalmazás és egy bővítmény kommunikáljon a szerződés megfelelő nézetei között. A szerződéseket, nézeteket és adaptereket szegmenseknek nevezzük, és a kapcsolódó szegmensek egy készlete egy folyamatot alkot. A folyamatok azok az alapok, amelyeken a .NET-keretrendszer bővítménymodellje támogatja a felderítést, az aktiválást, a biztonsági elkülönítést, a végrehajtás elkülönítését (alkalmazástartományok és folyamatok használatával), a kommunikációt, az élettartam-kezelést és a verziószámozást.

Ennek a támogatásnak az összege lehetővé teszi, hogy a fejlesztők olyan bővítményeket építsenek, amelyek integrálhatók a gazdaalkalmazások funkcióival. Egyes forgatókönyvek azonban megkövetelik, hogy a gazdagépalkalmazások megjelenítse a bővítmények által biztosított felhasználói felületeket. Mivel a .NET-keretrendszer minden bemutatótechnológiája saját modellel rendelkezik a felhasználói felületek implementálására, a .NET-keretrendszer bővítménymodellje nem támogatja az adott bemutatótechnológiát. Ehelyett a WPF kibővíti a .NET-keretrendszer bővítménymodellt a bővítmények felhasználói felületének támogatásával.

WPF-Add-Ins

A WPF a .NET-keretrendszer bővítménymodellel együtt lehetővé teszi számos olyan forgatókönyv kezelését, amelyekhez gazdagépalkalmazások szükségesek a bővítmények felhasználói felületeinek megjelenítéséhez. Ezeket a forgatókönyveket a WPF a következő két programozási modellel kezeli:

  1. A bővítmény egy felhasználói felületet ad vissza. A bővítmény egy felhasználói felületet ad vissza a gazdaalkalmazásnak a szerződés által meghatározott metódushíváson keresztül. Ez a forgatókönyv a következő esetekben használatos:

    • A bővítmény által visszaadott felhasználói felület megjelenése olyan adatoktól vagy feltételektől függ, amelyek csak futásidőben léteznek, például dinamikusan létrehozott jelentésektől.

    • A bővítmény által nyújtott szolgáltatások felhasználói felülete eltér a bővítményt használó gazdagépalkalmazások felhasználói felületétől.

    • A bővítmény elsősorban a gazdaalkalmazás szolgáltatását végzi, és felhasználói felülettel jelenti az állapotot a gazdaalkalmazásnak.

  2. A bővítmény egy felhasználói felület. A bővítmény a szerződés által meghatározott felhasználói felület. Ez a forgatókönyv a következő esetekben használatos:

    • A bővítmények nem nyújtanak más szolgáltatásokat, mint a megjelenített szolgáltatások, például a hirdetések.

    • A bővítmény által biztosított szolgáltatások felhasználói felülete minden olyan gazdagépalkalmazás esetében gyakori, amely használhatja ezt a bővítményt, például számológépet vagy színválasztót.

Ezek a forgatókönyvek megkövetelik, hogy a felhasználói felületi objektumok átadhatók legyenek a gazdaalkalmazás és a bővítményalkalmazás-tartományok között. Mivel a .NET-keretrendszer bővítménymodellje az alkalmazástartományok közötti távoli kommunikációra támaszkodik, a közöttük átadott objektumoknak távolról elérhetőknek kell lenniük.

A távoli elérhetőségű objektum egy osztály egy példánya, amely az alábbiak közül egyet vagy többet hajt végre:

Megjegyzés:

A távolról elérhető .NET-keretrendszer objektumok létrehozásával kapcsolatos további információkért lásd a Tárgyak távolról elérhetővé tételéről.

A WPF felhasználói felület típusai nem módosíthatók. A probléma megoldásához a WPF kibővíti a .NET-keretrendszer bővítménymodelljét, hogy a bővítmények által létrehozott WPF UI megjelenjen a gazdaalkalmazásokból. Ezt a támogatást a WPF kétféle módon biztosítja: az INativeHandleContract interfész és az FrameworkElementAdapters osztály által implementált két statikus módszer: ContractToViewAdapter és ViewToContractAdapter. Magas szinten ezeket a típusokat és módszereket a következő módon használják:

  1. A WPF megköveteli, hogy a bővítmények által biztosított felhasználói felületek olyan osztályok legyenek, amelyek közvetlenül vagy közvetve a FrameworkElement-ből származnak, mint például alakzatok, vezérlők, felhasználói vezérlők, elrendezéspanelek és lapok.

  2. Ahol a szerződés kimondja, hogy a bővítmény és a gazdaalkalmazás között egy felhasználói felület lesz átadva, azt INativeHandleContract-ként kell deklarálni (nem FrameworkElement); a INativeHandleContract a bővítmény felhasználói felületének távoli ábrázolása, amely átvihető az izolációs határokon.

  3. A FrameworkElement az alkalmazás tartományából való továbbítás előtt INativeHandleContract hívásával ViewToContractAdapter formába van csomagolva.

  4. Miután át lett adva a gazdaalkalmazás alkalmazástartományának, a INativeHandleContract elemet újra kell csomagolni FrameworkElement-ként, a ContractToViewAdapter meghívásával.

Az, hogy hogyan használják a INativeHandleContract, ContractToViewAdapter és ViewToContractAdapter elemeket, a konkrét forgatókönyvtől függ. A következő szakaszok az egyes programozási modellek részleteit ismertetik.

Add-In Felhasználói felületet ad vissza

Ahhoz, hogy egy bővítmény felhasználói felületet adjon vissza egy gazdagépalkalmazásnak, a következőkre van szükség:

  1. Létre kell hozni a gazdaalkalmazást, a bővítményt és a folyamatot a . NET-keretrendszer bővítményei és bővíthetőségi dokumentációja szerint.

  2. A szerződésnek implementálnia IContract kell, és a felhasználói felület visszaadásához a szerződésnek deklarálnia kell egy metódust, amelynek visszatérési értéke típus INativeHandleContract.

  3. A bővítmény és a gazdaalkalmazás között átadott felhasználói felületnek közvetlenül vagy közvetve a forrásból FrameworkElementkell származnia.

  4. A bővítmény által visszaadott felhasználói felületet az elkülönítési határ átlépése előtt át kell alakítani egy FrameworkElement-ből egy INativeHandleContract-ké.

  5. A visszaadott felhasználói felületet az elkülönítési határ átlépése után át kell alakítani egy INativeHandleContract-ből egy FrameworkElement-be.

  6. A gazdaalkalmazás megjeleníti a visszaadott FrameworkElement.

Egy felhasználói felületet visszaadó bővítmény implementálását bemutató példa: Felhasználói felületet visszaadó Add-In létrehozása.

Add-In Felhasználói felület

Ha egy bővítmény egy felhasználói felület, a következőkre van szükség:

  1. Létre kell hozni a gazdaalkalmazást, a bővítményt és a folyamatot a . NET-keretrendszer bővítményei és bővíthetőségi dokumentációja szerint.

  2. A bővítmény szerződési felületének implementálnia INativeHandleContractkell.

  3. A gazdaalkalmazásnak átadott bővítménynek közvetlenül vagy közvetve a forrásból FrameworkElementkell származnia.

  4. A bővítményt az elkülönítési határ átlépése előtt át kell alakítani a FrameworkElement-ről a INativeHandleContract-ra.

  5. A bővítményt az elkülönítési határ átlépése után át kell konvertálni INativeHandleContract-ból FrameworkElement-be.

  6. A gazdaalkalmazás megjeleníti a visszaadott FrameworkElement.

Egy példa arra, hogyan lehet egy felhasználói felületként működő bővítményt implementálni, a következőt lásd: Felhasználói felület létrehozása Add-In.

Több felhasználói felület visszaadása egy Add-In-ból

A bővítmények gyakran több felhasználói felületet biztosítanak a gazdagépalkalmazások megjelenítéséhez. Vegyük például egy olyan bővítményt, amely egy olyan felhasználói felület, amely állapotinformációkat is biztosít a gazdaalkalmazásnak, valamint felhasználói felületként is. Az ehhez hasonló bővítmények a Add-In Felhasználói felületet visszaadó modellek és Add-In Felhasználói felület modellek különböző technikáinak kombinációjával implementálhatók.

Add-Ins és XAML böngészőalkalmazások

Az eddigi példákban a gazdaalkalmazás egy telepített önálló alkalmazás volt. Az XAML böngészőalkalmazások (XBAP-k) azonban bővítményeket is üzemeltethetnek, bár az alábbi további buildelési és megvalósítási követelményekkel:

  • Az XBAP-alkalmazás manifestjét kifejezetten úgy kell konfigurálni, hogy letöltse a csővezetékeket (mappákat és összeszereléseket), valamint a bővítmény összeszerelést az ügyfélszámítógép ClickOnce gyorsítótárába, ugyanabban a mappában, mint az XBAP.

  • A bővítmények felderítéséhez és betöltéséhez használt XBAP-kódnak az XBAP ClickOnce alkalmazás-gyorsítótárát kell használnia folyamatként és bővítményhelyként.

  • Az XBAP-nek egy speciális biztonsági környezetbe kell betöltenie a bővítményt, ha a bővítmény a forráshelyen található laza fájlokra hivatkozik; XBAP-k üzemeltetésekor a bővítmények csak a gazdaalkalmazás forráshelyén található laza fájlokra hivatkozhatnak.

Ezeket a feladatokat részletesen az alábbi alszakaszok ismertetik.

A folyamat és a Add-In konfigurálása a ClickOnce üzembe helyezéséhez

Az XBAP-k letöltődnek a ClickOnce központi telepítési gyorsítótárában lévő biztonságos mappába, és onnan futnak. Ahhoz, hogy egy XBAP egy bővítményt üzemeltethessen, a folyamatot és a bővítményszerelvényt is le kell tölteni a biztonságos mappába. Ennek eléréséhez konfigurálnia kell az alkalmazásjegyzéket úgy, hogy a csővezeték és a bővítmény szerelvényét is tartalmazza letöltés céljából. Ez a legegyszerűbben a Visual Studióban történik, bár a pipeline-nak és a bővítményszerelvénynek a gazdagép XBAP-projektje gyökérmappájában kell lennie ahhoz, hogy a Visual Studio észlelje a pipeline szerelvényeket.

Ennek következtében az első lépés a csővezeték és a bővítményszerelvények létrehozása az XBAP-projekt gyökerénél az egyes csővezeték- és bővítményszerelvény-projektek build-kimenetének beállításával. Az alábbi táblázat a folyamatösszeállítási projektek és a beépülő modul összeszerelési projektek buildelési kimeneti útvonalait mutatja. Ezek a projektek ugyanabban a megoldásban és gyökérmappában találhatók, mint a gazdagép XBAP projektje.

1. táblázat: Az XBAP által üzemeltetett folyamatszerelvények kimeneti útvonalainak létrehozása

Csővezeték-szerelési projekt Kimeneti elérési út létrehozása
Szerződés ..\HostXBAP\Contracts\
Add-In nézet ..\HostXBAP\AddInViews\
In-Side adapter hozzáadása ..\HostXBAP\AddInSideAdapters\
Host-Side adapter ..\HostXBAP\HostSideAdapters\
Add-In ..\HostXBAP\AddIns\WPFAddIn1

A következő lépés a folyamatszerelvények és a bővítmények szerelvényének megadása XBAPs-tartalomfájlokként a Visual Studióban a következő lépésekkel:

  1. A folyamat és a bővítményszerelvény belefoglalása a projektbe úgy, hogy a jobb gombbal az egyes folyamatmappákra kattint a Megoldáskezelőben, és válassza a Belefoglalás a projektbe lehetőséget.

  2. Az egyes folyamatszerelvények és bővítmények összeállítási műveletének beállítása Tartalomra a Tulajdonságok ablakból.

Az utolsó lépés az alkalmazásjegyzék konfigurálása úgy, hogy tartalmazza a folyamat szerelvényfájljait és a bővítmény szerelvényfájljait letöltésre. A fájloknak a ClickOnce gyorsítótár azon mappájának gyökérmappájában levő almappákban kell lenniük, amelyeket az XBAP-alkalmazás használ. A konfiguráció a Következő lépéssel érhető el a Visual Studióban:

  1. Kattintson a jobb gombbal az XBAP-projektre, kattintson a Tulajdonságok, a Közzététel, majd az Alkalmazásfájlok gombra.

  2. Az Alkalmazásfájlok párbeszédpanelen állítsa az egyes folyamatok és a bővítmény DLL közzétételi állapotátBelefoglalás (Automatikus) értékre, és állítsa az egyes folyamatok letöltési csoportját és a bővítmény DLL-jének letöltési csoportját (Kötelező) értékre.

A folyamat és a Add-In használata az Alkalmazás Alapból

Ha a folyamat és a bővítmény a ClickOnce üzembe helyezéséhez van konfigurálva, a rendszer ugyanarra a ClickOnce cache-mappára tölti le őket, mint az XBAP. A folyamat és az XBAP-ből származó bővítmény használatához az XBAP-kódnak le kell szereznie őket az alkalmazásbázisból. A .NET-keretrendszer bővítménymodelljének különböző típusai és tagjai a folyamatok és bővítmények használatához különleges támogatást nyújtanak ehhez a forgatókönyvhöz. Először az elérési utat az enumerálási ApplicationBase érték azonosítja. Ezt az értéket a kapcsolódó bővítménytagok túlterhelésével használja az alábbi folyamatokat tartalmazó folyamatok használatára:

A gazdagép eredeti helyének elérése

Annak érdekében, hogy egy bővítmény hivatkozhasson a forráshelyről származó fájlokra, a bővítményt olyan biztonsági elkülönítéssel kell betölteni, amely megegyezik a gazdaalkalmazással. Ezt a biztonsági szintet az AddInSecurityLevel.Host enumerálási érték azonosítja, és a bővítmény aktiválásakor átadja a Activate metódusnak.

WPF Add-In architektúra

A legmagasabb szinten, ahogy láttuk, a WPF lehetővé teszi, hogy a .NET-keretrendszer bővítményei olyan felhasználói felületeket implementáljanak (amelyek közvetlenül vagy közvetve származnak FrameworkElement-ból) INativeHandleContract, ViewToContractAdapter és ContractToViewAdapter használatával. Az eredmény az, hogy a gazdaalkalmazás visszakap egy FrameworkElement, amely a gazdaalkalmazás felhasználói felületén jelenik meg.

Az egyszerű felhasználói felületi bővítmények esetében ez a fejlesztői igényeknek megfelelő részletesség. Az összetettebb forgatókönyvekhez, különösen azokhoz, amelyek további WPF-szolgáltatásokat próbálnak használni, például az elrendezést, az erőforrásokat és az adatkötést, részletesebb ismeretekre van szükség arról, hogy a WPF hogyan terjeszti ki a .NET-keretrendszer bővítménymodelljét felhasználói felületi támogatással annak előnyeinek és korlátainak megértéséhez.

A WPF alapvetően nem ad át felhasználói felületet egy bővítményből egy gazdaalkalmazásnak; ehelyett a WPF a WPF-együttműködés használatával átadja a felhasználói felület Win32 ablakleíróját. Ilyen esetben, amikor egy bővítmény felhasználói felületét átadják egy gazdaalkalmazásnak, a következő történik:

  • A bővítmény oldalán a WPF beszerez egy ablakfogópontot a gazdaalkalmazás által megjelenített felhasználói felülethez. Az ablakkezelőt egy belső WPF-osztály kapszulázza, amely a HwndSource származik és megvalósítja a INativeHandleContract-t. Az osztály egy példányát a függvény visszaadja ViewToContractAdapter , és a bővítmény alkalmazástartományából a gazdaalkalmazás alkalmazástartományába kerül.

  • A gazdaalkalmazás részéről a WPF újracsomagolja a HwndSource elemet egy belső WPF-osztályként, amely a HwndHost-ből származik, és felhasználja a INativeHandleContract-t. Az osztály egy példányát ContractToViewAdapter a gazdaalkalmazás adja vissza.

HwndHost arra létezik, hogy megjelenítse az ablakkezelők által azonosított felhasználói felületeket WPF felhasználói felületekről. További információ: WPF és Win32 Interoperation.

Összefoglalva, INativeHandleContract, ViewToContractAdapter, és ContractToViewAdapter azért léteznek, hogy lehetővé tegyék a WPF felhasználói felület ablakkezelőjének átadását egy bővítményből egy gazdagépalkalmazásnak, ahol azt egy HwndHost kapszulázza, és megjeleníti a gazdaalkalmazás felhasználói felületén.

Megjegyzés:

Mivel a gazdaalkalmazás kap egy parancsot HwndHost, a gazdaalkalmazás nem konvertálhatja a visszaadott ContractToViewAdapter objektumot a bővítmény által implementált típusra (például egy UserControl).

Természeténél fogva HwndHost bizonyos korlátozásokkal rendelkezik, amelyek befolyásolják, hogy a gazdagép-alkalmazások milyen módon használhatják őket. Azonban a WPF kiterjeszti a HwndHost több képességgel a bővítmény-szcenáriókhoz. Ezeket az előnyöket és korlátozásokat alább ismertetjük.

WPF Add-In előnyei

Mivel a WPF-bővítmények felhasználói felületei egy belső osztályt HwndHosthasználó gazdaalkalmazásokból jelennek meg, ezeket a felhasználói felületeket a WPF felhasználói felületi HwndHost szolgáltatásai, például az elrendezés, a renderelés, az adatkötés, a stílusok, a sablonok és az erőforrások képességei korlátozzák. A WPF azonban további képességekkel bővíti belső HwndHost alosztályát, amelyek az alábbiakat tartalmazzák:

  • A gazdaalkalmazás felhasználói felülete és a bővítmény felhasználói felülete közötti lapozás. Vegye figyelembe, hogy a "bővítmény egy felhasználói felület" programozási modell megköveteli a bővítményoldali adapter felülbírálását QueryContract a lapozás engedélyezéséhez, függetlenül attól, hogy a bővítmény teljes mértékben megbízható vagy részben megbízható.

  • A gazdaalkalmazás felhasználói felületeiről megjelenített bővítmények akadálymentességi követelményeinek teljesítése.

  • A WPF-alkalmazások biztonságos futtatásának engedélyezése több alkalmazástartomány-forgatókönyvben.

  • A bővítmények biztonsági elkülönítéssel (azaz részleges megbízhatósági biztonsági tesztkörnyezettel) való futtatásakor megakadályozza a bővítmények felhasználói felületének ablakkezelőihez való illegális hozzáférést. A hívás ViewToContractAdapter biztosítja ezt a biztonságot:

    • A "bővítmény egy felhasználói felületet ad vissza" programozási modell esetében az egyetlen módja annak, hogy a bővítmény felhasználói felületének ablakleíróját átengedje az elkülönítés határán, ha meghívja ViewToContractAdapter.

    • Az "add-in is a UI" programozási modell esetében szükséges a bővítményoldali adapter QueryContract felülbírálása és a ViewToContractAdapter hívása (amint az az előző példákban látható), valamint a bővítményoldali adapter implementációjának QueryContract hívása a gazdagépoldali adapterről.

  • Több alkalmazástartomány végrehajtási védelmének biztosítása. Az alkalmazástartományokra vonatkozó korlátozások miatt a bővítményalkalmazás-tartományokba bedobott nem kezelt kivételek a teljes alkalmazás összeomlását okozzák, annak ellenére, hogy az elkülönítési határ létezik. A WPF és a .NET-keretrendszer bővítménymodellje azonban egyszerű módot kínál a probléma megoldására és az alkalmazás stabilitásának javítására. A felhasználói felületet megjelenítő WPF-bővítmény létrehoz egy Dispatcher olyan szálat, amelyen az alkalmazástartomány fut, ha a gazdaalkalmazás WPF-alkalmazás. Az alkalmazástartományban előforduló összes kezeletlen kivételt észlelheti a UnhandledException WPF bővítmény Dispatchereseményének kezelésével. A Dispatcher a CurrentDispatcher tulajdonságból lekérhető.

WPF Add-In korlátozások

A HwndSource, HwndHost és az ablakfogópontok által biztosított alapértelmezett viselkedéshez hozzáadott előnyökön túl, a gazdaalkalmazásokból megjelenített bővítmények felhasználói felületeire is korlátozások vonatkoznak.

  • A gazdaalkalmazásból megjelenített bővítmények felhasználói felületei nem tartják tiszteletben a gazdaalkalmazás kivágási viselkedését.

  • Az együttműködési forgatókönyvekben a légtér fogalma a bővítményekre is vonatkozik (lásd a technológiai régiók áttekintését).

  • A gazdaalkalmazás felhasználói felületi szolgáltatásai, például az erőforrás-öröklés, az adatkötés és a parancsolás nem érhetők el automatikusan a bővítmény felhasználói felületei számára. Ha ezeket a szolgáltatásokat szeretné biztosítani a bővítménynek, frissítenie kell a csővezetéket.

  • A bővítmények felhasználói felületét nem lehet elforgatni, skálázni, elferdíteni vagy más módon átalakítani transzformációval (lásd Átalakítások áttekintése).

  • A System.Drawing névtérből származó rajzműveletek által renderelt kiegészítő felhasználói felületek tartalma alfa-keverést is tartalmazhat. A bővítmény felhasználói felületének és a gazdaalkalmazás felhasználói felületének azonban 100% átlátszatlannak kell lennie; más szóval a Opacity tulajdonságnak mindkettőn 1-nek kell lennie.

  • Ha a gazdaalkalmazás egy olyan ablakának tulajdonsága, amely egy bővítmény felhasználói felületét tartalmazza, AllowsTransparency van beállítva, a bővítmény nem látható. Ez akkor is igaz, ha a bővítmény felhasználói felülete 100% átlátszatlan (azaz a Opacity tulajdonság értéke 1).

  • A bővítmény felhasználói felületének a többi WPF-elem tetején kell megjelennie ugyanabban a felső szintű ablakban.

  • A bővítmény felhasználói felületének egyetlen része sem jeleníthető meg VisualBrush használatával. Ehelyett előfordulhat, hogy a bővítmény pillanatképet készít a létrehozott felhasználói felületről, hogy létrehozhasson egy bitképet, amely a szerződés által meghatározott metódusok használatával továbbítható a gazdaalkalmazásnak.

  • A médiafájlok nem játszhatók le egy MediaElement bővítmény felhasználói felületén.

  • A bővítmény felhasználói felületén létrehozott egéreseményeket a gazdaalkalmazás nem fogadja és nem kezeli, a IsMouseOver gazdaalkalmazás felhasználói felületének tulajdonsága pedig a következő értékkel rendelkezik false.

  • Amikor a fókusz a bővítmény felhasználói felületén lévő vezérlők között vált, a GotFocus és a LostFocus eseményeket sem fogadja, sem nem váltja ki a gazdaalkalmazás.

  • A gazdagépalkalmazásnak a bővítmény felhasználói felületét tartalmazó része nyomtatáskor fehéren jelenik meg.

  • A bővítmény felhasználói felülete által létrehozott összes kézbesítőt (lásd Dispatcher) manuálisan kell leállítani, mielőtt a tulajdonosi bővítményt eltávolítanák, ha a gazdaalkalmazás folytatja a végrehajtást. A szerződés olyan módszereket valósíthat meg, amelyek lehetővé teszik a gazdaalkalmazás számára, hogy jelezhesse a bővítményt a bővítmény eltávolítása előtt, ezáltal lehetővé téve, hogy a bővítmény felhasználói felülete leállítsa a diszpécsereket.

  • Ha egy bővítmény felhasználói felülete egy InkCanvas-t vagy egy InkCanvas-t tartalmaz, nem távolíthatja el a bővítményt.

Teljesítményoptimalizálás

Alapértelmezés szerint több alkalmazástartomány használata esetén az egyes alkalmazások által igényelt különböző .NET-keretrendszer-szerelvények mind betöltve lesznek az alkalmazás tartományába. Ennek eredményeképpen az új alkalmazástartományok létrehozásához és az alkalmazások elindításához szükséges idő befolyásolhatja a teljesítményt. A .NET-keretrendszer azonban lehetővé teszi, hogy csökkentse az indítási időket azáltal, hogy utasítja az alkalmazásokat: osszák meg a már betöltött assembly-ket az alkalmazási tartományok között. Ezt az LoaderOptimizationAttribute attribútummal teheti meg, amelyet a belépési pont metódusára (Main) kell alkalmazni. Ebben az esetben csak kóddal implementálhatja az alkalmazásdefiníciót (lásd : Alkalmazáskezelés áttekintése).

Lásd még

  • Last updated on