Űrlapok testreszabásának és szerkesztésének áttekintése a Service Manager Szerzői eszközzel

Cikk
09/26/2023

Fontos

A Service Manager ezen verziója elérte a támogatás végét. Javasoljuk, hogy frissítsen Service Manager 2022-re.

Az űrlap olyan ablak, amelyen keresztül a felhasználók használni tudják az adatbázisból származó objektumokat. Az űrlapok objektumok tulajdonságainak megtekintésére és szerkesztésére szolgálnak. Minden egyes űrlap meghatározott célosztályhoz kötődik, és csak az adott célosztály példányainak adatait jeleníti meg. Az űrlapok mezőkből épülnek fel. Általában minden mező az űrlap célzott osztályának egy adott tulajdonságához van kötve. Az incidensűrlap például az incidensobjektumhoz kötődik. Éppen ezért az adatbázisban szereplő incidensobjektumokkal kapcsolatos adatokat jeleníti meg.

A Service Manager űrlap a Microsoft .NET-keretrendszer-szerelvény Windows megjelenítési alaprendszer (WPF) űrlap-implementációját és egy Service Manager felügyeleti csomag űrlapdefinícióját tartalmazza. Az űrlap-definíció meghatározza az űrlap által képviselt osztályt, valamint az űrlap más egyéb tulajdonságait.

Az űrlapokkal kapcsolatos legfontosabb fogalmak

Az űrlapok testreszabása előtt ismerkedjen meg az alábbi, az űrlapokkal kapcsolatos alapfogalmakkal.

Űrlapok használata

Az űrlapdefiníciókat tartalmazó felügyeleti csomag Service Manager importálásakor az űrlapdefiníciók az adatbázisban lesznek tárolva. Később, amikor a felhasználó egy objektum megjelenítését igénylő Service Manager konzolfeladatot kezdeményez, Service Manager meg kell találnia egy űrlapot a kért objektum megjelenítéséhez. Service Manager hozzáfér az adatbázishoz, és megkeresi az objektumhoz definiált űrlapot. Ha az objektumhoz nincs űrlap definiálva, Service Manager az objektum szülőobjektumához definiált űrlapot keres. Service Manager továbbra is a teljes objektum öröklődési hierarchiájában keres, amíg meg nem talál egy definiált űrlapot.

Általános űrlapok

Ha Service Manager nem talál űrlapot az objektumhoz vagy annak szülőobjektumaihoz, Service Manager dinamikusan létrehoz egy alapértelmezett általános űrlapot az objektumhoz. Az általános űrlap egy rendszer által létrehozott űrlap, amely elegendő az egyszerű űrlapok használatához. Az általános űrlap gyors és egyszerű módszer az objektumokhoz tartozó űrlapok előállítására úgy, hogy nincs szükség űrlap-definícióra.

Alapértelmezés szerint az általános űrlap egyszerű elrendezésben jeleníti meg az űrlap összes tulajdonságát, amelyet nem lehet módosítani. Az általános űrlap megjeleníti az űrlap öröklési hierarchiájában található összes szülőobjektum tulajdonságait, és ezt a viselkedést nem módosíthatja. Az általános űrlapot korlátozott mértékben lehet testreszabni. Megadhatja például azokat a tulajdonságokat, amelyeket meg szeretne jeleníteni az általános űrlapon; az általános űrlap azonban nem használható a testreszabás alapjaként. Ha később egyéni űrlapot definiál az objektumhoz, az egyéni űrlap felülírja az objektum általános űrlapját.

Az általános űrlapok tulajdonságainak elrejtéséről és az általános űrlapok testreszabásának egyéb módjairól az Űrlapinfrastruktúra és az Általános űrlap áttekintése című blogbejegyzésben talál további információt.

Kombinált osztályok űrlapokban

Egyes esetekben több osztályból származó információkat kell megjeleníteni egy űrlapon. Ehhez hozzon létre egy kombinált osztályt , majd kössön egy mezőt az űrlapon a kombinált osztályhoz. A kombinált osztályokkal kapcsolatos további információkért lásd : A System Center közös sémájának módosításai.

Az űrlap funkcionális jellemzői

Az űrlapok működési jellemzőit az alábbiakban foglaltuk össze:

Inicializálás
Méret és hely
Frissítés
Változások elküldése

Az alábbi szakaszok ismertetik ezeket az jellemzőket.

Inicializálás

Az inicializálás során az űrlap Extensible Application Markup Language (XAML) nyelvét elemzi a rendszer, és az űrlap összes vezérlőjét példányosítjuk és betöltjük. Az űrlap Betöltött eseménye azt jelzi, hogy az űrlap és az összes tartalmazott elem mikor lett betöltve. Az adatbetöltési műveletek aszinkronok. Ezért előfordulhat, hogy a célpéldány nem érhető el a Betöltött esemény létrehozásakor. Ehelyett a DataContextChanged eseményt kell használni az értesítéshez, ha a célpéldány be van állítva az űrlaphoz. A DataContext tulajdonság PropertyChanged eseménye a DataContextChanged esemény helyett használható.

Javasoljuk, hogy a Loaded eseményt használja a vezérléssel kapcsolatos egyéni inicializáláshoz, majd használja a DataContextChanged vagy a PropertyChanged eseményeket a DataContext tulajdonságban a célpéldányhoz kapcsolódó egyéni inicializáláshoz.

Méret és hely

Ha egy űrlap előugró ablakban jelenik meg, a kezdeti mérete az űrlap Szélesség, Magasság, MinWidth és MinHeight tulajdonságai alapján lesz meghatározva. Ha ezek a tulajdonságok nincsenek beállítva az űrlaphoz, az űrlap kezdeti mérete a tartalma alapján lesz kiszámítva.

Javasoljuk, hogy a tulajdonságok értékét az alábbiak szerint állítsa be:

Állítsa be az űrlap Szélesség és Magasság tulajdonságát az ideális méret explicit megadásához. Érdemes lehet ezeket a tulajdonságokat automatikus értékre állítani. Ezzel beállítja az űrlap szélességét és magasságát a tartalom mérete alapján.
Állítsa be az űrlap MinWidth és MinHeight tulajdonságát az űrlaphoz elfogadható legkisebb ablak megadásához. Ha a felhasználó a megadottnál kisebbre kicsinyíti az ablakot, az éppen nem látható tartalom elérésére használható gördítősávok jelennek meg.

Ha az űrlap az Service Manager űrlap gazdagépén van tárolva, az utoljára használt méretet és helyet megőrzi a rendszer, hogy az űrlapot ugyanazon a futtatási munkameneten belül ugyanaz a felhasználó megjelenítse.

Frissítés

Az űrlap célpéldánya megváltozhat, ha egy Frissítés parancsot futtat az űrlapon. A parancs kezelője új adatokat kérdez le az adatbázisból. Az adatok érkezésekor az űrlap DataContext tulajdonságának értéke az új célpéldányra van állítva, és a DataContextChanged esemény létrejön.

Az űrlap első betöltésekor létrehozott DataContextChanged esemény és a Frissítés parancs kezeléséhez létrehozott esemény megkülönböztetéséhez ellenőrizze az esemény argumentumainak OldValue tulajdonságát. Az űrlap inicializálásakor ez a tulajdonság nullértékű.

Változások elküldése

A Service Manager űrlapgazda előugró ablaka gombokat biztosít az űrlapon végrehajtott módosítások elküldéséhez és az előugró ablak bezárásához.

Amikor egy felhasználó az Űrlap alkalmazás gombját választja egy űrlaphoz, az űrlap célpéldánya el lesz küldve a tárterületre. Ez a művelet szinkron; ezért a felhasználó nem szerkesztheti az űrlapot, amíg a küldési művelet be nem fejeződik. Ha hiba történik az űrlap elküldésekor, hibaüzenet jelenik meg. Az űrlap nyitva marad, és további módosítások is végezhetők rajta. Javasoljuk, hogy a felhasználók minél gyakrabban mentsék a változtatásokat, így elkerülhetik az ütközéseket, ha más is szerkeszti ugyanannak az űrlapnak egy másik példányát.

Ha a felhasználó az OK gombot választja, a viselkedés az Alkalmazhoz hasonló, azzal a kivételsel, hogy ha az űrlap beküldési művelete sikeres, az űrlap és a gazdagép ablaka bezárul.

Ha a felhasználó a Mégse gombot választja, megjelenik egy párbeszédpanel, amely megkéri a felhasználót, hogy erősítse meg a műveletet. A felhasználó kiválaszthatja az Igen lehetőséget, és elveszítheti a módosításokat, vagy kiválaszthatja a Nem lehetőséget, és visszatérhet az űrlaphoz.

Általános irányelvek és ajánlott eljárások űrlapokhoz

A Service Manager funkcióit űrlapok hozzáadásával vagy módosításával bővítheti. Ez a szakasz a Service Manager űrlapok létrehozásának és használatának ajánlott eljárásait ismerteti, amelyek különböző eszközökkel és közvetlenül szkriptelési űrlapdefiníciókkal hozhatók létre és használhatók.

Ez a szakasz elsősorban azokat a partnereket és ügyfeleket célozza meg, akik tapasztaltak a saját egyéni űrlapok Windows megjelenítési alaprendszer (WPF) és a Microsoft Visual Studio Team System vagy a Microsoft Expression Blend használatával történő elkészítésében.

Az új űrlapok létrehozásával kapcsolatos általános irányelvek az alábbiak.

Használjon szabványos vezérlőket.
Kövesse az általános űrlaptervezési irányelveket.
Kerülje a kód mögötti kódot.
Használjon kivételkezelést.
Vegye figyelembe az űrlapok testreszabási és frissítési lehetőségeit.
Nevezze el az összes testreszabható vezérlőt.
Kapcsolja az űrlapot adatforrásokhoz.
Használjon Service Manager űrlapok infrastruktúra-ellenőrzési szabályait, értékkonvertátorokat és hibasablonokat.
Használja az űrlap-infrastruktúra parancsait és eseményeit.

Az irányelvekkel kapcsolatos további információkért lásd a következő részeket.

Standard vezérlők használata

Az űrlapokon használt vezérlők a következő típusúak lehetnek:

Standard vezérlők. Ilyenek a .NET könyvtár vezérlői, például a kombinált lista és a listamező.
Egyéni vezérlők. Ilyenek azok a további vezérlők, amelyeket az űrlap készítője vagy harmadik fél hoz létre.

Tipp

Ha szabványos vezérlőket használ és lehetőség szerint kerüli az egyéni vezérlők létrehozását, az űrlapokkal kapcsolatos felhasználói élmény egységesebb lesz. Ha mindenképpen szükség van egyéni vezérlő létrehozására, annak vizuális megjelenését és viselkedését, valamint a logikai viselkedést különítse el úgy, hogy vezérlősablonok használatával definiálja a vezérlő megjelenését. Ideális esetben minden Windows-témához külön vezérlősablon tartozik.

Kövesse az általános űrlaptervezési irányelveket

Űrlap tervezésekor a nyilvános tervezési irányelvek segítségével győződjön meg arról, hogy az űrlap felhasználóbarát, és hogy megfelel a gyakori felhasználói interakciós paradigmáknak.

Az általános Windows-kialakításról további információt a Windows felhasználói élményének interakciós irányelvei című témakörben talál.

Továbbá:

Az információkat ossza szét több lapra, hogy az űrlap egyszerűbb és könnyebben olvasható legyen. Adja meg a leggyakrabban használt információkat az első lapon, és az azt követő lapokon kisebb jelentőséggel bíró információkat.
Használjon elrendezési paneleket az űrlap vezérlőinek elrendezéséhez. Ez biztosítja, hogy az űrlap megfelelően viselkedjen átméretezésekor és honosított állapotában.
Kerülje a vezérlők megjelenítési tulajdonságainak külön-külön történő beállítását, ehelyett használjon stílusokat. Ez lehetővé teszi az űrlapok összes vezérlőjének megjelenését a stílus módosításával, és elősegíti a kapcsolódó űrlapok egységes megjelenését.

A kód mögötti kód elkerülése

A kód mögötti kifejezés azt a kódot írja le, amely egy XAML-lap lefordításakor a korrektúra által definiált objektumokkal összekapcsolt kódot írja le. A kód mögötti kód használatának korlátozása az űrlapon a lehető legnagyobb mértékben. Célszerű egy űrlap kódját beágyazni a vezérlőbe, mert később könnyebb módosítani a kódot. Ehelyett használja a Service Manager űrlapinfrastruktúra által támogatott deklaratív képességeket értékkonverziók és érvényesítési szabályok meghatározásához az űrlapon.

Általános útmutatóként korlátoznia kell a mögöttes kód használatát olyan helyzetekre, amikor nem lehet biztosítani a szükséges funkciókat az XAML deklaratív képességeinek használatával, a WPF-ben és az űrlapok infrastruktúra-kódtárában meghatározott osztályokkal. Még akkor is érdemes lehet áthelyezni a kód mögé implementált funkciókat egy segédtárba, majd hivatkozni rá az XAML-ből.

Kivételkezelés belefoglalása

Győződjön meg arról, hogy az űrlap kódja kivételkezelést tartalmaz, hogy az űrlap a tervezési fázisban is betölthető legyen a szerkesztőeszközben és a Service Manager konzolon futásidőben.

Fontolja meg az űrlapok testreszabását és frissítését

Új űrlap tervezésekor érdemes megfontolnia az űrlap jövőbeli testreszabásait és frissítéseit. Annak érdekében, hogy az űrlapok testreszabása és frissítése a testreszabások megőrzése mellett is lehetséges legyen, kövesse az ebben a szakaszban korábban ismertetett irányelveket és tippeket, valamint az alábbi irányelveket:

Az űrlap tervezésekor érdemes lehet a jövőbeni testreszabásokat és frissítéseket is figyelembe venni. Az űrlapok valószínűleg fejlődni fognak a jövőbeli verziókban, és fontos figyelembe venni, hogy a felhasználók hogyan frissíthetnek az űrlap új verzióira, miközben megőrzik az eredeti űrlap testreszabását. Képzelje el például, hogy frissített űrlapot tesz elérhetővé azután, hogy a felhasználók már rengeteg energiát fordítottak az eredeti űrlap testreszabására. A felhasználók ilyenkor azt várják el, hogy a testreszabások a verziófrissítés során megőrződjenek.
Adjon egyedi nevet az űrlap minden vezérlőjének, hogy a testreszabások a vezérlőkre is alkalmazhatók legyenek. Az űrlapok testreszabásai műveletekként tárolódnak, amelyek egy adott vezérlőt vagy vezérlőcsoportot céloznak meg. A célvezérlőre név szerint hivatkozik, ezért fontos megőrizni a vezérlők nevét az űrlap különböző verzióiban. Ha egy vezérlőelemnek nincs neve, az Űrlap testreszabása Szerkesztő létrehoz egy nevet, de a létrehozott név nem marad meg az űrlap különböző verzióiban.
Győződjön meg arról, hogy a vezérlőnevek nem módosíthatók az űrlap különböző verzióiban. Így az adott vezérlőn egy korábbi verzióban végzett testreszabás az űrlap új verziójában is alkalmazható lesz ugyanarra a vezérlőre.
Ha lehetséges, az űrlap frissítésekor kerülje a vezérlők más helyre történő áthelyezését ugyanazon a lapon belül. A testreszabás során a felhasználók gyakran helyezik át az űrlap vezérlőit más helyre. Ha módosítja egy vezérlő helyét az űrlap új verziójában, fennáll annak a veszélye, hogy az új vezérlő helye átfedésben lehet egy olyan vezérlővel, amelyet a felhasználó áthelyezett.
Ha lehetséges, ne váltsa át a vezérlőket a lapok között egy meglévő űrlapra való frissítés tervezésekor. A vezérlőket név és azon lap azonosítja, amelyen találhatók. Ha az űrlap új verziójában egy vezérlőt másik lapra helyez át, azzal érvénytelenné válhatnak a felhasználó által az adott vezérlőn végzett testreszabások, mert a vezérlőt nem lehet azonosítani.
Ha az űrlapra való frissítés új vezérlőket tartalmaz, érdemes lehet az új vezérlőket egy új lapra felvenni. Ez a legbiztonságosabb módja annak, hogy ne zavarjanak a meglévő lapok és vezérlők felhasználói testreszabásai.
Ügyeljen a vezérlők kötésére. A csak olvasható vezérlőknek csak egyirányú kötéseket kell használniuk.

Nevezze el az összes testreszabható vezérlőt

Ügyeljen arra, hogy a vezérlőnevek írják le, milyen adatokhoz van kötve a vezérlő, illetve mi a funkciója.

Az űrlap kötése adatforrásokhoz

Az űrlapok fő célja egyetlen objektum megjelenítése a Service Manager adatbázisból. Ezt az objektumot célpéldánynak nevezzük, amelyet mindig egy űrlap DataContext tulajdonsága határoz meg (amely a FrameworkElement osztálytól öröklődik).

Fontos

Ne módosítsa az űrlap DataContext tulajdonságát. Az űrlap futtatókörnyezete ezt a tulajdonságot használja az űrlap célpéldányának azonosításához.

A Service Manager adatmodellben egy célpéldány BindableDataItem objektumként jelenik meg. Ez az osztály összesíti a mögöttes szoftverfejlesztői készlet (SDK) objektumot, és a tulajdonságait egy indexelőn keresztül teszi elérhetővé, amely paraméterként egy tulajdonságnevet vesz fel.

A BindableDataItem osztály az ICustomTypeDescriptort is implementálja, amely lehetővé teszi a BindableDataItem osztály használatát a WPF-kötés adatforrásaként. Az alábbiakban egy példa látható egy célpéldány tulajdonságának a TextBox vezérlőelem Text tulajdonságához való kötésére:


<TextBox Name="textBoxDescription" Text="{Binding Path=Summary}"/>

Nem szükséges megadni a kötés forrását , mert a célpéldányok az űrlap DataContext elemét használják, amely az űrlap összes vezérlőjének alapértelmezett forrása .

Az űrlap vezérlői a célpéldányon kívül más adatforrásokhoz is köthetők, és az űrlap-infrastruktúra-kódtár számos olyan vezérlőt tartalmaz, amelyek implicit módon hajtják végre a kötést. A példányválasztó vezérlő például az adatforráshoz van kötve, amely a választható példányok gyűjteményét biztosítja. További adatforrásokat deklaratív módon is definiálhat az ObjectDataProvider és az XmlDataProvider osztály használatával.

Az űrlapinfrastruktúra a célpéldányt tekinti az űrlap egyetlen olvasási/írási adatforrásának. Ezért a Submit parancs végrehajtása csak a célpéldányon végrehajtott módosításokat tárolja. Az űrlap egyéb adatforrásait a rendszer írásvédettként kezeli.

Az Service Manager űrlapok infrastruktúra-ellenőrzési szabályainak, értékkonvertátorainak és hibasablonjainak használata

Azt javasoljuk, hogy az űrlapokon az űrlapok infrastruktúra-érvényesítési szabályait használva jelöljön ki érvénytelen adatbevitelt. A WPF kötési infrastruktúra támogatja az egyirányú vagy kétirányú kötéssel rendelkező adatforráshoz kötött vezérlőtulajdonságok ellenőrzését. A kötésobjektum rendelkezik egy ValidationRules-gyűjteménysel , amely tetszőleges számú ValidationRule objektumot tartalmazhat. Amikor a vezérlőből az adatforrásba küld adatokat, a rendszer meghívja az ValidationRule objektumokat az érték ellenőrzéséhez.

Az űrlapinfrastruktúra-kódtár számos ellenőrzési szabályt tartalmaz, amelyek a leggyakoribb eseteket kezelik. Az űrlap-infrastruktúra az ellenőrzési szabályok használatával határozza meg, hogy az űrlap tartalma benyújtható-e tárolásra. Egy űrlap Küldés gombja például letiltható, ha egy vezérlő érvényesítési hibát jelez az űrlapon.

Javasoljuk, hogy használja az űrlap-infrastruktúra kódtárához tartozó egyéni hibasablont. Ha egy vezérlő ellenőrzési hibát tartalmaz, alapértelmezés szerint piros szegéllyel jelenik meg. A WPF lehetővé teszi egyéni hibajelző meghatározását az Validation.ErrorTemplate tulajdonsággal, amely bármely vezérlőn beállítható. A Service Manager űrlapok infrastruktúra-kódtára egyéni hibasablont tartalmaz, amely a WPF piros szegélye helyett egy hibaikont jelenít meg. Emellett ha az egérrel a hibaikonra mutatnak, elemleírás jelenik meg a hibaüzenettel. A hibaüzenetnek meg kell határoznia, miért nem felelt meg a vezérlőben megadott adat az ellenőrzésnek.

A következő példa azt mutatja be, hogyan hivatkozható a hibasablon az XAML-ben:


<TextBox Text="{Binding SomeProperty}"
         scwpf:Validation.ValueRequired="True"
         Validation.ErrorTemplate="{DynamicResource {ComponentResourceKey {x:Type scwpf:Validation}, InvalidDataErrorTemplate}}"/>

Ha a beépített érvényesítési szabályok nem biztosítják a szükséges érvényesítési logikát, javasoljuk, hogy egyéni érvényesítési szabályokat állítson össze a logika megjelenítéséhez. Ez lehetővé teszi a normál és egyéni ellenőrzési logika párhuzamos működését a közös ellenőrzési mechanizmusban.

Ha az érvényesítési szabályok mechanizmusa nem felel meg egy adott forgatókönyvnek, akkor inkább a FormEvents.PreviewSubmitEvent parancsot kell kezelnie, és onnan kell futtatnia az érvényesítést.

A következő példakód az egyéni ellenőrzés futtatását mutatja be:


void MyForm_Loaded(object sender, RoutedEventArgs e)
{
    // hook to handle form events
    this.AddHandler(
        FormEvents.PreviewSubmitEvent,
        new EventHandler<PreviewFormCommandEventArgs>(this.OnPreviewSubmit));
}
private void OnPreviewSubmit(object sender, PreviewFormCommandEventArgs e)
{
    string errorMessage;
    bool result = this.DoVerify(out errorMessage);
    if (!result)
    {
        // cancel Submit operation
        e.Cancel = true;
        // display error message
        MessageBox.Show(errorMessage);
    }
}
internal bool DoVerify(out string errorMessage)
{
    // Do custom verification and return true to indicate that
    // validation check has passed; otherwise return false and
    // populate errorMessage argument
}

Űrlapinfrastruktúra-parancsok és események használata

Az űrlapinfrastruktúra számos, űrlapon futtatható parancsot tesz elérhetővé. Ezek a parancsok a következők:

FormsCommand.Submit, amely menti az űrlap célpéldányát.
FormsCommand.SubmitAndClose, amely menti az űrlap célpéldányát, és bezárja az űrlapot.
FormsCommand.Refresh, amely megismétli az űrlap célpéldányának lekérdezését.
FormCommands.Cancel, amely elveti az összes módosítást, és bezárja az űrlapot.

A parancsok mindegyike eseményekbe van ágyazva, amelyek a parancs futása előtt és után aktiválódnak.

A parancs előtt a következő események aktiválódnak:

A FormEvents.PreviewSubmit esemény a FormCommand.Submit parancs előtt, a FormEvents.Submit esemény pedig a FormCommand.Submit parancs után jön létre.
A FormEvents.PreviewRefresh esemény a FormCommands.Refresh parancs előtt, a FormCommand.Refreshed parancs pedig a FormCommand.Submit parancs után jön létre.
A FormEvents.PreviewCancel esemény a FormCommands.Cancel parancs előtt, a FormCommand.Cancel esemény pedig a FormCommand.Cancel parancs után jön létre.

Az előnézeti események egy PreviewFormCommandEventArgs objektumon haladnak át. Ez az objektum tartalmaz egy mutable Cancel tulajdonságot, amely megakadályozza a megfelelő parancs futtatását, ha a tulajdonság értéke igaz.

A parancs utáni események átadnak egy FormCommandExecutedEventArgs objektumot . Ez az objektum egy Result tulajdonságot tartalmaz, amely azt jelzi, hogy a parancs futtatása sikeres volt-e, megszakítva vagy hibát okozott-e. Hiba esetén a FormCommandExecutedEventArgs objektum Error tulajdonsága arra a kivételre hivatkozik, amely információt nyújt a hibáról.

Az űrlapparancsok programozottan és deklaratív módon is engedélyezhetőek, letilthatók és futtathatók.

Az űrlapparancsok programozott engedélyezéséhez hozzon létre egy CommandBinding parancsot az űrlap és a kapcsolódó parancs között.

Az alábbi példában egy parancskötés jön létre az űrlap és a Frissítés parancs között, és ehhez a parancshoz két kezelő van definiálva. Az első kezelő azt adja vissza, hogy a Frissítés parancs futtatható-e, a második kezelő pedig ténylegesen tartalmazza-e a Frissítés parancs implementációját:


    public class MyForm : UserControl
    {
        public MyForm()
        {
            // do standard initialization
            // establish CommandBinding for Refresh command
            this.CommandBindings.Add(
                new CommandBinding(FormCommands.Refresh, this.ExecuteRefresh, this.CanExecuteRefresh));
        }
        private void CanExecuteRefresh(
              object sender,
              CanExecuteRoutedEventArgs e)
        {
            // put your logic that determines whether Refresh
// can be executed here
            bool canExecute = true;
            BindableDataItem dataItem = this.DataContext as BindableDataItem;
            if (dataItem)
            {
                canExecute = dataItem["Status"] != "New";
            }
            e.CanExecute = canExecute;
        }
        private void ExecuteRefresh(
            object sender,
            ExecutedRoutedEventArgs e)
        {
            // here is placeholder for the code that has do be
// executed upon running Refresh command
        }
    }

Az űrlapparancsok kezelőit deklaratív módon is definiálhatja. Ezt egy RoutedCommandTriggert használó szabályobjektum használatával teheti meg. A következő példakód a kezelők deklaratív definiálását mutatja be:


    <scwpf:BusinessLogic.Rules>
        <scwpf:RuleCollection>
            <scwpf:Rule>
                <scwpf:Rule.Triggers>
                    <scwpf:RoutedCommandTrigger
RoutedCommand="{x:Static scwpf:FormCommands.Refresh}"/>
                </scwpf:Rule.Triggers>
                <scwpf:Rule.Conditions>
                    <scwpf:PropertyMatchCondition
                        Binding="{Binding Status}"
                        Value="New"
                        Operation="NotEquals" />
                </scwpf:Rule.Conditions>
                <!-- Use RuleAction objects to define the logic that executed
                upon running Refresh command; this can be left empty -->
            </scwpf:Rule>
        </scwpf:RuleCollection>
    </scwpf:BusinessLogic.Rules>