Overzicht van het aanpassen en ontwerpen van formulieren met het Service Manager-bewerkingsprogramma

Belangrijk

Deze versie van Service Manager heeft het einde van de ondersteuning bereikt. U wordt aangeraden een upgrade uit te voeren naar Service Manager 2022.

Een formulier is een venster waarin gebruikers handelingen kunnen uitvoeren op objecten uit de database. Gebruikers kunnen een formulier gebruiken om de eigenschappen van objecten weer te geven en te bewerken. Elk formulier is gekoppeld aan een bepaalde klasse en hierin wordt alleen informatie weergegeven voor exemplaren van de doelklasse. Een formulier bevat velden. Normaal gesproken is elk veld gebonden aan een specifieke eigenschap van de doelklasse van het formulier. Het incidentformulier is bijvoorbeeld gekoppeld aan het incidentobject. In het incidentformulier wordt dus informatie weergegeven over incidentobjecten in de database.

Een Service Manager formulier bestaat uit de implementatie van het wpf-formulier (Windows Presentation Foundation) in een Microsoft .NET Framework-assembly en een formulierdefinitie in een Service Manager management pack. Met de formulierdefinitie wordt opgegeven welke klasse het formulier vertegenwoordigt. Daarnaast worden de andere eigenschappen van het formulier opgegeven.

Belangrijkste concepten over formulieren

Voordat u formulieren aanpast, dient u bekend te zijn met de volgende formulierconcepten.

Hoe formulieren worden gebruikt

Wanneer het management pack met de formulierdefinities wordt geïmporteerd in Service Manager, worden de formulierdefinities opgeslagen in de database. Wanneer de gebruiker later een Service Manager consoletaak start waarvoor de weergave van een object is vereist, moet Service Manager een formulier vinden om het aangevraagde object weer te geven. Service Manager opent de database en zoekt naar een formulier dat voor dat object is gedefinieerd. Als er geen formulier is gedefinieerd voor het object, zoekt Service Manager naar een formulier dat is gedefinieerd voor het bovenliggende object van het object. Service Manager blijft de overnamehiërarchie van het hele object doorzoeken totdat er een gedefinieerd formulier wordt gevonden.

Algemene formulieren

Als Service Manager geen formulier kunt vinden voor het object of voor een van de bovenliggende objecten, bouwt Service Manager dynamisch een standaard algemeen formulier voor dat object. Het algemene formulier is een door het systeem gegenereerd formulier dat voldoende is voor eenvoudig formuliergebruik. Het generieke formulier vormt een snelle en eenvoudige manier om een formulier voor objecten te maken zonder formulierdefinities.

In het algemene formulier worden standaard alle eigenschappen van het formulier weergegeven in een eenvoudige indeling die u niet kunt wijzigen. In het algemene formulier worden de eigenschappen van alle bovenliggende objecten in de overnamehiërarchie van het formulier weergegeven. U kunt dit gedrag niet wijzigen. U kunt het generieke formulier in beperkte mate aanpassen. U kunt bijvoorbeeld de eigenschappen opgeven die u in het algemene formulier wilt weergeven; Het algemene formulier kan echter niet worden gebruikt als basis voor aanpassing. Als u later een aangepast formulier voor dat object definieert, overschrijft het aangepaste formulier het algemene formulier van het object.

Zie het blogbericht Overzicht van de infrastructuur formulieren en het algemene formulier voor informatie over het verbergen van eigenschappen in een algemeen formulier en andere manieren waarop u een algemeen formulier kunt aanpassen.

Combinatieklassen in formulieren

Soms hebt u een formulier nodig om informatie weer te geven die afgeleid is van meer dan een klasse. Hiervoor maakt u een combinatieklasse en koppelt u vervolgens een veld op het formulier aan de combinatieklasse. Zie Wijzigingen in het algemene schema van System Center voor meer informatie over combinatieklassen.

Functionele aspecten van een formulier

Een formulier heeft de volgende functionele aspecten:

1. Initialisatie

2. Grootte en locatie

3. Vernieuwen

4. Wijzigingen verzenden

Deze aspecten worden in de volgende rubrieken beschreven.

Initialisatie

Tijdens de initialisatie wordt de Extensible Application Markup Language (XAML) van een formulier geparseerd en worden alle besturingselementen in het formulier geïnstantieerd en geladen. De gebeurtenis Geladen van het formulier geeft aan wanneer het formulier en alle ingesloten elementen zijn geladen. Bewerkingen voor het laden van gegevens zijn asynchroon. Daarom is het doelexemplaar mogelijk niet beschikbaar wanneer de gebeurtenis Geladen wordt gegenereerd. In plaats daarvan moet de gebeurtenis DataContextChanged worden gebruikt voor een melding wanneer het doelexemplaar is ingesteld voor het formulier. De gebeurtenis PropertyChanged voor de eigenschap DataContext kan worden gebruikt in plaats van de gebeurtenis DataContextChanged .

U wordt aangeraden de gebeurtenis Loaded te gebruiken voor aangepaste initialisatie met betrekking tot besturingselementen en vervolgens de gebeurtenissen DataContextChanged of PropertyChanged te gebruiken voor de eigenschap DataContext voor aangepaste initialisatie met betrekking tot het doelexemplaar.

Grootte en locatie

Wanneer een formulier wordt weergegeven in een pop-upvenster, wordt de oorspronkelijke grootte bepaald op basis van de eigenschappen Width, Height, MinWidth en MinHeight van het formulier. Als deze eigenschappen niet zijn ingesteld voor het formulier, wordt de oorspronkelijke grootte van het formulier berekend op basis van de inhoud.

Het is aan te bevelen om deze eigenschappen als volgt in te stellen:

• Stel de eigenschappen Width en Height van het formulier in om expliciet de ideale grootte op te geven. U kunt deze eigenschappen instellen op de automatische waarde. Hiermee wordt de breedte en hoogte van het formulier ingesteld op basis van de grootte van de inhoud.

• Stel de eigenschappen MinWidth en MinHeight van het formulier in om het kleinste venster op te geven dat acceptabel is voor het formulier. Als een gebruiker de grootte van het venster wijzigt in een kleiner formaat dan is opgegeven, worden er schuifbalken weergegeven waarmee naar de verborgen formulierinhoud kan worden geschoven.

Wanneer het formulier wordt gehost in de Service Manager formulierhost, blijven de laatst gebruikte grootte en locatie behouden voor latere weergave van dat formulier door dezelfde gebruiker binnen dezelfde uitvoeringssessie.

Vernieuwen

Het doelexemplaar van een formulier kan worden gewijzigd als gevolg van het uitvoeren van een opdracht Vernieuwen op het formulier. De handler voor deze opdracht haalt nieuwe gegevens op uit de database. Wanneer de gegevens binnenkomen, wordt de waarde van de eigenschap DataContext van het formulier ingesteld op het nieuwe doelexemplaar en wordt de gebeurtenis DataContextChanged gegenereerd.

Als u onderscheid wilt maken tussen de DataContextChanged-gebeurtenis die is gegenereerd toen het formulier voor het eerst werd geladen en de gebeurtenis die is gegenereerd om een opdracht Vernieuwen te verwerken, controleert u de eigenschap OldValue van de gebeurtenisargumenten die met de gebeurtenis worden doorgegeven. Deze eigenschap is NULL als het formulier zojuist is geïnitialiseerd.

Wijzigingen verzenden

Het pop-upvenster van de formulierhost in Service Manager bevat knoppen voor het verzenden van wijzigingen die in het formulier zijn aangebracht en voor het sluiten van het pop-upvenster.

Wanneer een gebruiker de knop Toepassen voor een formulier selecteert, wordt het doelexemplaar van het formulier verzonden voor opslag. Deze bewerking is synchroon; daarom kan de gebruiker het formulier pas bewerken als de inzending is voltooid. Als er tijdens de verzending van het formulier een fout optreedt, wordt er een foutbericht weergegeven. Het formulier blijft geopend voor verdere wijzigingen. Wij raden gebruikers aan om regelmatig hun wijzigingen toe te passen om conflicten te voorkomen als een ander exemplaar op hetzelfde moment wordt bewerkt.

Als de gebruiker de knop OK selecteert, is het gedrag vergelijkbaar met Toepassen. Als de bewerking voor het indienen van het formulier is geslaagd, worden het formulier en het hostvenster gesloten.

Als de gebruiker de knop Annuleren selecteert, verschijnt er een dialoogvenster waarin de gebruiker wordt gevraagd de bewerking te bevestigen. De gebruiker kan Ja selecteren en wijzigingen verliezen, of Nee selecteren en terugkeren naar het formulier.

Algemene richtlijnen en aanbevolen procedures voor formulieren

U kunt functies van Service Manager uitbreiden door formulieren toe te voegen of te wijzigen. In deze sectie worden enkele aanbevolen procedures beschreven voor het maken en gebruiken van Service Manager formulieren, met behulp van verschillende hulpprogramma's en het rechtstreeks uitvoeren van scriptformulierdefinities.

Deze sectie is voornamelijk bedoeld voor partners en klanten die ervaring hebben met het bouwen van hun eigen aangepaste formulieren met behulp van Windows Presentation Foundation (WPF) en Microsoft Visual Studio Team System of Microsoft Expression Blend.

De algemene richtlijnen voor het ontwerpen van een nieuw formulier zijn als volgt.

• Gebruik standaardbesturingselementen.
• Volg algemene richtlijnen voor het ontwerpen van formulieren.
• Vermijd code-behind.
• Neem uitzonderingsverwerking op.
• Houd rekening met aanpassingen en upgrades van formulieren.
• Geef alle aanpasbare besturingselementen een naam.
• Bind het formulier aan gegevensbronnen.
• Gebruik Service Manager validatieregels voor de infrastructuur van formulieren, waarde convertors en foutsjablonen.
• Gebruik formulierinfrastructuuropdrachten en gebeurtenissen.

Zie de volgende secties voor informatie over deze richtlijnen.

Standaardbesturingselementen gebruiken

Besturingselementen die in een formulier worden gebruikt kunnen zijn:

• Standaardbesturingselementen. Dit omvat ook .NET-bibliotheekbesturingselementen, zoals keuzelijsten met invoervak en keuzelijsten.
• Aangepaste besturingselementen. Dit zijn extra besturingselementen die door de auteur van het formulier of door derden worden gemaakt.

Tip

Als u waar mogelijk standaardbesturingselementen gebruikt en zo min mogelijk aangepaste besturingselementen, bevordert u de consistentie met betrekking tot de gebruikerservaring van formulieren. Als u toch een aangepast besturingselement moet maken, onderscheid het uiterlijk en gedrag en het logische gedrag dan door besturingselementsjablonen te gebruiken om het uiterlijk van het besturingselement te definiëren. Er moet bij voorkeur een afzonderlijk besturingselementsjabloon zijn voor elk Windows-thema.

Volg de algemene richtlijnen voor het ontwerpen van formulieren

Wanneer u een formulier ontwerpt, gebruikt u openbare ontwerprichtlijnen om ervoor te zorgen dat het formulier gebruiksvriendelijk is en voldoet aan algemene paradigma's voor gebruikersinteractie.

Zie Richtlijnen voor interactie tussen Windows-gebruikerservaringen voor meer informatie over het algemene Windows-ontwerp.

Daarnaast:

• Verdeel informatie over meerdere tabbladen om het formulier eenvoudiger en gemakkelijker leesbaar te maken. Neem de meest gebruikte informatie op het eerste tabblad op en informatie die minder belangrijk is op de volgende tabbladen.
• Gebruik lay-outdeelvensters om besturingselementen op het formulier te plaatsen. Dit zorgt ervoor dat het formulier correct werkt wanneer het formaat wordt gewijzigd en gelokaliseerd.
• Stel de visuele eigenschappen van besturingselementen niet afzonderlijk in, maar maak gebruik van stijlen. Hierdoor kunt u het uiterlijk van alle besturingselementen in een reeks formulieren wijzigen door de stijl te wijzigen en wordt een consistent uiterlijk in gerelateerde formulieren bevorderd.

Code-behind vermijden

Code-behind is een term die de code beschrijft die wordt gekoppeld aan door markeringen gedefinieerde objecten wanneer een XAML-pagina wordt gecompileerd. Beperk het gebruik van code-behind in een formulier zoveel mogelijk. Het verdient de voorkeur dat u de code voor een formulier insluit in het besturingselement zelf, omdat het later gemakkelijker is om die code te wijzigen. Gebruik in plaats daarvan de declaratieve mogelijkheden die worden ondersteund door de infrastructuur voor Service Manager formulieren om waardeconversies en validatieregels in het formulier te definiëren.

Als algemene richtlijn moet u het gebruik van code-behind beperken tot situaties waarin het niet mogelijk is om de vereiste functionaliteit te bieden met behulp van de declaratieve mogelijkheden van XAML, met klassen die zijn gedefinieerd in de WPF en de bibliotheek voor de formulierinfrastructuur. Zelfs dan kunt u overwegen om de functionaliteit die is geïmplementeerd in code-behind te verplaatsen naar een helperbibliotheek en er vervolgens naar te verwijzen vanuit de XAML.

Uitzonderingsafhandeling opnemen

Zorg ervoor dat de code in het formulier uitzonderingsafhandeling bevat, zodat het formulier zowel tijdens de ontwerpfase in het ontwerpprogramma als in de Service Manager-console tijdens runtime kan worden geladen.

Aanpassing en upgrades van formulieren overwegen

Wanneer u een nieuw formulier ontwerpt, moet u toekomstige aanpassingen en upgrades naar dat formulier overwegen. Om ervoor te zorgen dat het mogelijk is om een formulier aan te passen en bij te werken met behoud van aanpassingen, volgt u de richtlijnen en tips die eerder in deze sectie zijn gegeven, samen met de volgende richtlijnen:

• Overweeg toekomstige aanpassingen en upgrades vroeg tijdens het ontwerpen van het formulier. Formulieren zullen waarschijnlijk in toekomstige versies veranderen en het is belangrijk om te bedenken hoe gebruikers een upgrade naar nieuwe versies van uw formulier kunnen uitvoeren met behoud van hun aanpassingen aan het oorspronkelijke formulier. U kunt bijvoorbeeld een bijgewerkt formulier leveren nadat gebruikers al veel hebben geïnvesteerd in het aanpassen van uw oorspronkelijke formulier. Gebruikers verwachten dat hun aanpassingen behouden blijven na de upgrade naar de nieuwe versie.

• Geef elk besturingselement in het formulier een unieke naam om het mogelijk te maken aanpassingen toe te passen op besturingselementen. Aanpassingen van formulieren worden opgeslagen als een set acties die zijn gericht op een bepaald besturingselement of een bepaalde set besturingselementen. Naar het doelbesturingselement wordt verwezen met de naam. Daarom is het belangrijk om namen van besturingselementen in verschillende versies van het formulier te behouden. Als een besturingselement geen naam heeft, genereert de Editor Formulieraanpassing een naam, maar blijft de gegenereerde naam niet behouden in verschillende versies van het formulier.

• Zorg ervoor dat de namen van besturingselementen onveranderbaar blijven in verschillende versies van het formulier. Hierdoor zorgt u ervoor dat in een eerdere versie gemaakte aanpassingen van een bepaald besturingselement kunnen worden toegepast op hetzelfde besturingselement in een nieuwe versie van het formulier.

• Vermijd het indien mogelijk besturingselementen naar een andere locatie op hetzelfde tabblad te verplaatsen wanneer u een formulier upgradet. Een veelvoorkomende aanpassing door gebruikers is het verplaatsen van besturingselementen in het formulier naar een andere locatie. Als u de locatie van een besturingselement in een nieuwe versie van het formulier wijzigt, bestaat het risico dat de nieuwe locatie van het besturingselement overlapt met een besturingselement dat de gebruiker heeft verplaatst.

• Vermijd indien mogelijk het verplaatsen van besturingselementen tussen tabbladen wanneer u een update van een bestaand formulier ontwerpt. Besturingselementen worden geïdentificeerd op naam en op het tabblad waarop ze zich bevinden. Door in een nieuwe versie van het formulier een besturingselement naar een ander tabblad te verplaatsen, gaan aanpassingen die de gebruiker in dat besturingselement heeft gemaakt wellicht verloren, omdat het doelbesturingselement niet kan worden geïdentificeerd.

• Wanneer de update van een formulier nieuwe besturingselementen bevat, kunt u overwegen de nieuwe besturingselementen toe te voegen aan een nieuw tabblad. Dit is de veiligste manier om te voorkomen dat gebruikersaanpassingen in de bestaande tabbladen en besturingselementen worden verstoord.

• Wees u ervan bewust hoe besturingselementen zijn gebonden. Alleen-lezen besturingselementen mogen alleen bindingen in één richting gebruiken.

Alle aanpasbare besturingselementen een naam geven

Zorg ervoor dat de namen van de besturingselementen beschrijven aan welke gegevens elk besturingselement is gebonden of wat het doet.

Het formulier binden aan gegevensbronnen

Het belangrijkste doel van een formulier is om één object uit de Service Manager-database te visualiseren. Dit object wordt een doelexemplaren genoemd, die altijd wordt opgegeven door de eigenschap DataContext van een formulier (die wordt overgenomen van de klasse FrameworkElement ).

Belangrijk

Wijzig de eigenschap DataContext van het formulier niet. Deze eigenschap wordt in de formulierhostingomgeving gebruikt om de doelinstantie van het formulier te identificeren.

In het Service Manager gegevensmodel wordt een doelexemplaren weergegeven als een BindableDataItem-object. Met deze klasse wordt het onderliggende SDK-object (Software Development Kit) samengevoegd en worden de eigenschappen ervan weergegeven via een indexeerfunctie, die een eigenschapsnaam als parameter gebruikt.

De klasse BindableDataItem implementeert ook de ICustomTypeDescriptor, waardoor de klasse BindableDataItem kan worden gebruikt als gegevensbron voor WPF-binding. Hier volgt een voorbeeld van het binden van een eigenschap van een doelexemplaren aan de eigenschap Text van een tekstvakbesturingselement :

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

Het is niet nodig om de bron van de binding op te geven, omdat de doelexemplaren zijn ingesteld als de DataContext van het formulier, die fungeert als de standaardbron voor alle besturingselementen op het formulier.

Besturingselementen op het formulier kunnen worden gebonden aan andere gegevensbronnen dan het doelexemplaren en de bibliotheek met de formulierinfrastructuur bevat veel besturingselementen waarmee de binding impliciet wordt uitgevoerd. Zo is het besturingselement instantiekiezer gebonden aan de gegevensbron, die de verzameling van instanties biedt waaruit kan worden gekozen. Het is ook mogelijk om aanvullende gegevensbronnen declaratief te definiëren met behulp van de klassen ObjectDataProvider en XmlDataProvider .

De infrastructuur van formulieren beschouwt het doelexemplaren als de enige gegevensbron voor lezen/schrijven op het formulier. Daarom worden bij de implementatie van de opdracht Verzenden alleen de wijzigingen opgeslagen die zijn aangebracht in het doelexemplaren. Andere gegevensbronnen in het formulier worden behandeld als alleen-lezen.

Gebruik Service Manager formulieren voor validatieregels voor infrastructuur, waarde-convertors en foutsjablonen

We raden u aan om validatieregels voor formulierinfrastructuur in formulieren te gebruiken om ongeldige gegevensinvoer aan te wijzen. De INFRASTRUCTUUR voor WPF-binding ondersteunt validatie voor besturingselementeigenschappen die zijn gebonden aan een gegevensbron met bindingen in één richting of in twee richtingen. Het bindingsobject heeft een validatieregelverzameling die een willekeurig aantal Validatieregelobjecten kan bevatten. Wanneer gegevens van het besturingselement naar de gegevensbron worden gepusht, worden de ValidationRule-objecten aangeroepen om de waarde te valideren.

De infrastructuurbibliotheek voor formulieren bevat veel validatieregels die de meest voorkomende gevallen verwerken. De formulierinfrastructuur maakt gebruik van de validatieregels om te bepalen of de formulierinhoud kan worden verstuurd om te worden opgeslagen. De knop Verzenden van een formulier kan bijvoorbeeld worden uitgeschakeld als er een besturingselement is met een validatiefout in het formulier.

Wij raden u aan de aangepaste foutsjabloon te gebruiken die wordt geleverd bij de formulierinfrastructuurbibliotheek. Als een besturingselement een validatiefout heeft, wordt het standaard weergegeven met een rode rand. De WPF maakt het mogelijk om een aangepaste foutindicator te definiëren via de eigenschap Validation.ErrorTemplate , die kan worden ingesteld voor elk besturingselement. De infrastructuurbibliotheek Service Manager formulieren bevat een aangepaste foutsjabloon, die een foutpictogram weergeeft in plaats van de rode wpf-rand. Verder wordt er een tooltip met een foutbericht weergegeven wanneer de gebruiker het foutpictogram aanwijst met de muis. Het foutbericht dient de reden aan te geven waarom de gegevens in het besturingselement niet voldoen aan de validatie.

Het volgende voorbeeld laat zien hoe u de foutsjabloon in XAML gebruikt:

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

Als ingebouwde validatieregels niet de vereiste validatielogica bieden, raden we u aan aangepaste validatieregels te maken die deze logica vertegenwoordigen. Dit maakt het mogelijk dat standaard- en aangepaste validatielogica samen voorkomen binnen het gemeenschappelijke validatieafhandelingsmechanisme.

Als het mechanisme voor validatieregels niet geschikt is voor een bepaald scenario, moet u in plaats daarvan FormEvents.PreviewSubmitEvent verwerken en de validatie daar uitvoeren.

Het volgende codevoorbeeld geeft een voorbeeld van het patroon dat u kunt gebruiken om aangepaste validatie uit te voeren:

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
}

Opdrachten en gebeurtenissen voor formulierinfrastructuur gebruiken

De formulierinfrastructuur bevat veel opdrachten die kunnen worden uitgevoerd op een formulier. Deze opdrachten zijn:

• FormsCommand.Submit, waarmee het doelexemplaren van het formulier worden opgeslagen.

• FormsCommand.SubmitAndClose, waarmee het doelexemplaren van het formulier worden opgeslagen en het formulier wordt gesloten.

• FormsCommand.Refresh, waarmee de query voor het doelexemplaren van het formulier wordt herhaald.

• FormCommands.Cancel, waarmee alle wijzigingen worden genegeerd en het formulier wordt gesloten.

Elk van deze opdrachten staat tussen gebeurtenissen die worden gegenereerd voor en nadat de opdracht wordt uitgevoerd.

De volgende gebeurtenissen worden gegenereerd voor de opdracht:

• De gebeurtenis FormEvents.PreviewSubmit wordt gegenereerd vóór de opdracht FormCommand.Submit en de gebeurtenis FormEvents.Submitted wordt gegenereerd na de opdracht FormCommand.Submit .

• De gebeurtenis FormEvents.PreviewRefresh wordt gegenereerd vóór de opdracht FormCommands.Refresh en de opdracht FormCommand.Refreshed wordt gegenereerd na de opdracht FormCommand.Submit .

• De gebeurtenis FormEvents.PreviewCancel wordt gegenereerd vóór de opdracht FormCommands.Cancel en de gebeurtenis FormCommand.Canceled wordt gegenereerd na de opdracht FormCommand.Cancel .

De preview-gebeurtenissen geven een PreviewFormCommandEventArgs-object door. Dit object bevat een veranderlijke eigenschap Annuleren die voorkomt dat de bijbehorende opdracht wordt uitgevoerd wanneer de eigenschap is ingesteld op true.

De gebeurtenissen na de opdracht geven een FormCommandExecutedEventArgs-object door. Dit object bevat de eigenschap Result die aangeeft of het uitvoeren van de opdracht is geslaagd, is geannuleerd of een fout heeft veroorzaakt. In het geval van een fout verwijst de eigenschap Error van het object FormCommandExecutedEventArgs naar de uitzondering die informatie over de fout biedt.

Het is mogelijk om formulieropdrachten zowel programmatisch als declaratief in te schakelen, uit te schakelen en uit te voeren.

Als u formulieropdrachten programmatisch wilt inschakelen, maakt u een CommandBinding tussen het formulier en de bijbehorende opdracht.

In het volgende voorbeeld wordt een opdrachtbinding tot stand gebracht tussen het formulier en de opdracht Vernieuwen en zijn er twee handlers gedefinieerd voor deze opdracht. De eerste handler retourneert of de opdracht Vernieuwen kan worden uitgevoerd, en de tweede handler bevat daadwerkelijk de implementatie van de opdracht Vernieuwen :

    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
        }
    }

U kunt handlers voor formulieropdrachten ook declaratief definiëren. U kunt dit doen door een Rule-object te gebruiken dat gebruikmaakt van een RoutedCommandTrigger. In het volgende code voorbeeld ziet u hoe u handlers declaratief kunt definiëren:

    <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>

Volgende stappen

• Formulieren aanpassen en ontwerpen met het Service Manager-bewerkingsprogramma.
• Pas het standaardformulier voor incidenten aan voor het voorbeeldscenario van het bewerkingsprogramma.