Översikt över anpassning och redigering av formulär Service Manager redigeringsverktyget

Viktigt

Den här Service Manager har nått slutet av supporten rekommenderar vi att du uppgraderar till Service Manager 2022.

Ett formulär är ett fönster som gör det möjligt för användare att interagera med objekt från databasen. Användare kan använda ett formulär för att visa och redigera egenskaper för objekt. Varje formulär är kopplat till en viss klass, och det visar bara information om instanser i den målklassen. Ett formulär innehåller fält. Vanligtvis är varje fält bundet till en specifik egenskap för formulärets målklass. Incidentformuläret är till exempel kopplat till incidentobjektet. Incidentformuläret visar därför information om incidentobjekt i databasen.

Ett Service Manager-formulär består av Windows Presentation Foundation(WPF)-formulärimplementering i en Microsoft .NET Framework-sammansättning och en formulärdefinition i ett Service Manager-hanteringspaket. Formulärdefinitionen anger den klass som formuläret representerar, tillsammans med formulärets övriga egenskaper.

Viktiga begrepp om formulär

Det här är en beskrivning av vad du bör veta innan du börjar anpassa formulär.

Hur formulär används

När det hanteringspaket som innehåller formulärdefinitionerna importeras till Service Manager lagras formulärdefinitionerna i databasen. Senare, när användaren startar en Service Manager-konsolaktivitet som kräver visning av ett objekt, måste Service Manager hitta ett formulär för att visa det begärda objektet. Service Manager åtkomst till databasen och söker efter ett formulär som har definierats för objektet. Om inget formulär har definierats för objektet Service Manager efter ett formulär som har definierats för objektets överordnade objekt. Service Manager fortsätter att söka i hela objektets arvshierarki tills den hittar ett definierat formulär.

Allmänna formulär

Om Service Manager kan hitta något formulär för objektet eller för något av dess överordnade objekt, skapar Service Manager dynamiskt ett allmänt standardformulär för objektet. Det generiska formuläret är ett systemgenererat formulär som räcker för enkel formuläranvändning. Det är ett snabbt och enkelt sätt att skapa ett formulär för objekt som saknar formulärdefinitioner.

Som standard innehåller ett allmänt formulär alla formuläregenskaper i en enkel layout som inte kan ändras. Alla överordnade objekt i formulärets ärvda hierarki visas som standard. Detta går inte heller att ändra. Det går att göra vissa anpassningar av ett allmänt formulär, t.ex. ange vilka egenskaper som ska visas. Men formuläret kan inte användas som grund för anpassning. Om du senare definierar ett anpassat formulär för objektet skriver ditt anpassade formulär över objektets allmänna formulär.

Information om hur du döljer egenskaper i ett allmänt formulär och andra sätt som du kan anpassa ett allmänt formulär på finns i blogginlägget Overview of the Forms Infrastructure and the Generic Form (Översikt över formulärinfrastrukturen och det allmänna formuläret).

Kombinationsklasser i formulär

Ibland behöver man kunna visa information från flera klasser i ett formulär. Det gör du genom att skapa en kombinationsklass och sedan binda ett fält i formuläret till kombinationsklassen. Mer information om kombinationsklasser finns i Ändringar i System Center common schema.

Funktionella aspekter av ett formulär

Ett formulär har följande funktioner:

1. Initiering

2. Storlek och plats

3. Uppdatera

4. Skicka ändringar

Funktionerna beskrivs i avsnitten nedan.

Initiering

Under initieringen parsas ett formulärs Extensible Application Markup Language (XAML) och alla kontroller i formuläret instansieras och läses in. Formulärets inlästa händelse anger när formuläret och alla inneslutna element har lästs in. Dataläsningsåtgärder är asynkrona. Målinstansen kanske därför inte är tillgänglig när händelsen Inläst utlöses. I stället måste DataContextChanged-händelsen användas för meddelanden när målinstansen har angetts för formuläret. Händelsen PropertyChanged för egenskapen DataContext kan användas i stället för DataContextChanged-händelsen .

Vi rekommenderar att du använder händelsen Inläst för kontrollrelaterad anpassad initiering och sedan använder händelserna DataContextChanged eller PropertyChanged i egenskapen DataContext för anpassad initiering relaterad till målinstans.

Storlek och plats

När ett formulär visas i ett popup-fönster bestäms dess ursprungliga storlek baserat på formulärets egenskaper Bredd, Höjd, MinWidthoch MinHeight. Om dessa egenskaper inte har angetts för formuläret beräknas formulärets ursprungliga storlek baserat på dess innehåll.

Vi rekommenderar att du gör följande inställningar för egenskaperna:

• Ange egenskaperna Breddoch Höjd för formuläret för att uttryckligen ange den perfekta storleken. Överväg att ange dessa egenskaper till värdet Auto. Då beräknas formulärets bredd och höjd efter innehållet.

• Ange egenskaperna MinWidth ochMinHeight för formuläret för att ange det minsta fönstret som är acceptabelt för formuläret. Om användaren sedan gör fönstret mindre än vad som specificerats här, visas rullningslister i formulärfönstret.

När formuläret finns i Service Manager-formulärvärden bevaras den senast använda storleken och platsen för efterföljande visning av formuläret av samma användare i samma körningssession.

Uppdatera

Målinstansen för ett formulär kan ändras när ett uppdateringskommando körs i formuläret. Hanteraren för detta kommando hämtar nya data ur databasen. När data tas emot anges formulärets Egenskapsvärde för DataContext till den nya målinstansen och Händelsen DataContextChanged utlöses.

Om du vill skilja mellan datacontextChanged-händelsen som uthöjdes när formuläret först läses in och händelsen som uthöjdes för att hantera ett uppdateringskommando kontrollerar du egenskapen OldValue för händelseargumenten som skickas med händelsen. Egenskapen har ett nollvärde om formuläret bara har initierats.

Skicka ändringar

Popup-fönstret för formulärvärd i Service Manager innehåller knappar för att skicka ändringar som görs i formuläret och för att stänga popup-fönstret.

När en användare klickar på knappen Tillämpa för ett formulär skickas formulärets målinstans för lagring. Åtgärden sker synkront, och användaren kan alltså inte göra ändringar i formuläret förrän åtgärden är slutförd. Ett felmeddelande visas om åtgärden inte kan slutföras. Formuläret är då fortfarande öppet och ändringar kan göras. Användarna bör verkställa sina ändringar ofta, så att de inte hamnar i konflikt med andra instanser av formuläret som kanske redigeras samtidigt.

Om användaren klickar på OK-knappen liknar beteendet Tillämpa, förutom att formuläret och värdfönstret stängs om formulärinskickningen lyckas.

Om användaren klickar på knappen Avbryt visas en dialogruta där användaren uppmanas att bekräfta åtgärden. Användaren kan klicka på Ja och förlora ändringar, eller klicka på Nej och återgå till formuläret.

Allmänna riktlinjer och metodtips för formulär

Du kan utöka funktionerna i Service Manager genom att lägga till eller ändra formulär. Det här avsnittet beskriver några metodtips för att skapa och använda Service Manager formulär, med hjälp av olika verktyg och skriptformulärdefinitioner direkt.

Det här avsnittet riktar sig främst till partner och kunder som har erfarenhet av att skapa egna anpassade formulär med hjälp av Windows Presentation Foundation (WPF) och Microsoft Visual Studio Team System eller Microsoft Expression Blend.

Nedan beskrivs de generella riktlinjerna för redigering av ett nytt formulär.

• Använd standardkontroller.
• Följ de generella riktlinjerna för formulärdesign.
• Undvik kod bakom.
• Inkludera undantagshantering.
• Överväg om formulären ska anpassas och uppgraderas.
• Namnge alla anpassningsbara kontroller.
• Bind formuläret till datakällor.
• Använd Service Manager valideringsregler för formulärinfrastruktur, värdekonverterare och felmallar.
• Använd formulärinfrastrukturskommandon och händelser.

Information om dessa riktlinjer finns i följande avsnitt.

Använda standardkontroller

Följande kontroller kan användas i ett formulär:

• Standardkontroller. Här ingår .NET-bibliotekskontroller, till exempel kombinationsrutor och listrutor.
• Anpassade kontroller. Det omfattar ytterligare kontroller som skapats av formulärförfattaren eller av en tredje part.

Tips

Om du använder standardkontroller så långt möjligt och undviker att skapa anpassade kontroller, främjar du också en enhetlig användarupplevelse av formulären. Om du måste skapa en anpassad kontroll ska du separera det visuella utseendet och beteendet från det logiska beteendet genom att använda kontrollmallar när du definierar kontrollens utseende. Företrädesvis bör det finnas en separat kontrollmall för varje Windows-tema.

Följ allmänna riktlinjer för formulärdesign

När du utformar ett formulär ska du använda riktlinjer för offentlig design för att säkerställa att formuläret är användarvänligt och att det följer vanliga paradigm för användarinteraktion.

Mer information om allmän Windows finns i Windows riktlinjer för användarupplevelseinteraktion.

Dessutom gäller följande:

• Dela upp informationen på flera flikar så att formuläret blir lättare att läsa. Lägg den information som används mest på den första fliken och mindre viktig information på efterföljande flikar.
• Använd layoutpaneler när du placerar kontrollerna på formuläret. Det säkerställer att formuläret fungerar som avsett vid storleksändring och lokalisering.
• Undvik att ställa in visuella egenskaper för enstaka kontroller. Använd stilar istället. Då blir det också möjligt för dig att ändra utseendet för alla kontroller på flera formulär i taget genom att ändra stilen. Det ger också ett konsekvent utseende för flera relaterade formulär.

Undvik att koda efter

Kod bakom är en term som beskriver den kod som är ansluten till påläggsdefinierade objekt när en XAML-sida kompileras. Begränsa användningen av kod bakom i ett formulär så mycket som möjligt. Det rekommenderas att du bäddar in koden för ett formulär i själva kontrollen, eftersom det är lättare att ändra sådan kod längre fram. Använd i stället de deklarativa funktioner som stöds av Service Manager formulärinfrastruktur för att definiera värdekonverteringar och valideringsregler i formuläret.

Som en allmän riktlinje bör du begränsa användningen av kod bakom till situationer där det inte går att tillhandahålla nödvändiga funktioner med hjälp av deklarativa funktionerna i XAML, med klasser som definieras i WPF och formulärinfrastrukturbiblioteket. Överväg även att flytta funktionerna som implementeras i kod bakom till ett hjälpbibliotek och sedan referera till dem från XAML.

Inkludera undantagshantering

Se till att koden i formuläret innehåller undantagshantering så att formuläret kan läsas in både under designfasen i redigeringsverktyget och i Service Manager konsolen vid körning.

Överväg formuläranpassning och uppgraderingar

När du designar ett nytt formulär bör du överväga vilka anpassningar och uppgraderingar som eventuellt kan behöva göras i framtiden av formuläret. Du säkerställer att formuläret kan anpassas och uppgraderas utan att anpassningarna förloras om du följer riktlinjerna och tipsen ovan, kombinerat med följande riktlinjer:

• Överväg framtida anpassningar och uppgraderingar på ett tidigt stadium, redan medan du designar formuläret. Det är mycket troligt att formulär kommer att fortsätta att utvecklas och det är viktigt att tänka igenom hur användarna ska kunna uppgradera till nya versioner av formuläret samtidigt som deras anpassningar av det ursprungliga formuläret bevaras. Ibland kanske du vill erbjuda ett uppdaterat formulär trots att användarna redan har gjort omfattande anpassningar av det ursprungliga formuläret. Användarna förväntar sig att deras anpassningar ska överleva versionsuppgraderingen.

• Ange ett unikt namn för varje kontroll i formuläret så att det blir möjligt att tillämpa anpassningarna på kontrollerna. Formuläranpassningar lagras som en uppsättning åtgärder som riktas mot en specifik kontroll eller uppsättning kontroller. Målkontrollen refereras till med namnet, och det är därför viktigt att kontrollnamnen bevaras mellan olika versioner av formuläret. Om en kontroll saknar namn genereras ett namn av redigeraren för formuläranpassning, men detta namn bevaras inte mellan olika versioner av formuläret.

• Säkerställ att kontrollnamnen inte kan ändras mellan olika versioner av formuläret. Då kan du också vara säker på att anpassningarna för en viss kontroll i en tidigare version kan tillämpas på samma kontroll i en ny version av formuläret.

• Om möjligt bör du undvika att flytta kontroller till en annan plats på samma flik när du uppgraderar ett formulär. En vanlig användaranpassning består i att flytta kontroller på formuläret till en annan plats. Om du ändrar platsen för en kontroll i en ny version av formuläret, finns det en risk för att den nya platsen för kontrollen överlappar en kontroll som användaren har flyttat på.

• Om möjligt bör du undvika att flytta kontroller mellan flikar när du designar en uppdatering av ett befintligt formulär. Kontroller identifieras både med namnet och den flik där de är placerade. Om du flyttar en kontroll från en flik till en annan i den nya versionen av formuläret, kan anpassningar som användaren har gjort på den kontrollen förstöras, eftersom anpassningarna inte kan identifiera målkontrollen.

• När uppdateringen av ett formulär innehåller nya kontroller bör du överväga att lägga till de nya kontrollerna på en ny flik. Det är det säkraste sättet att undvika att störa eventuella användaranpassningar av befintliga flikar och kontroller.

• Var noggrann med bindningen för kontrollerna. Skrivskyddade kontroller bör endast använda envägsbindningar.

Namnge alla anpassningsbara kontroller

Säkerställ att kontrollnamnen beskriver vilka data som kontrollen är bunden till, eller beskriv vad kontrollen gör.

Binda formuläret till datakällor

Huvudsyftet med ett formulär är att visualisera ett enda objekt från Service Manager databasen. Det här objektet kallas en målinstans, som alltid anges av egenskapen DataContext för ett formulär (som ärvs från klassen FrameworkElement ).

Viktigt

Ändra inte formulärets DataContext-egenskap . Värdmiljön för formulären använder den här egenskapen för att identifiera formulärets målinstans.

I den Service Manager datamodellen representeras en målinstans som ett BindableDataItem-objekt. Den här klassen aggregerar det underliggande DEVELOPMENT KIT-objektet (SDK) och exponerar dess egenskaper via en indexerare, som tar ett egenskapsnamn som en parameter.

BindableDataItem-klassen implementerar även ICustomTypeDescriptor, vilket gör det möjligt att använda klassen BindableDataItem som datakälla för WPF-bindning. Följande är ett exempel på bindning av en målinstansegenskap till textegenskapen för en TextBox-kontroll :

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

Det är inte nödvändigt att ange källan för bindningen eftersom målinstanserna anges som DataContext för formuläret, som fungerar som standardkälla för alla kontroller i formuläret.

Kontrollerna i formuläret kan bindas till andra datakällor än målinstansen, och formulärinfrastrukturbiblioteket innehåller ett antal kontroller som genomför bindningen implicit. Kontrollen för inställning av instans är till exempel bunden till datakällan, vilket innebär att det finns en samling med instanser att välja mellan. Det är också möjligt att definiera ytterligare datakällor deklarativt med klasserna ObjectDataProvider och XmlDataProvider .

Formulärinfrastrukturen betraktar målinstansen som den enda läs-/skrivdatakällan i formuläret. Implementeringen av kommandot Submit lagrar därför bara de ändringar som görs i målinstansen. Övriga datakällor för formuläret behandlas som skrivskyddade.

Använd Service Manager valideringsregler för formulärinfrastruktur, värdekonverterare och felmallar

Vi rekommenderar att du använder formulärens infrastruktursvalideringsregler i formulär för att ange datainfogning som inte är giltig. WPF-bindningsinfrastrukturen stöder validering av kontrollegenskaper som är bundna till en datakälla med antingen envägs- eller tvåvägsbindningar. Bindningsobjektet har en ValidationRules-samling som kan innehålla valigt antal ValidationRule-objekt . När data skickas från kontrollen till datakällan anropas ValidationRule-objekten för att verifiera värdet.

Formulärinfrastrukturbiblioteket innehåller ett antal valideringsregler som hanterar de vanligaste fallen. Formulärinfrastrukturen utnyttjar valideringsreglerna för att avgöra huruvida formulärinnehållet kan skickas för lagring. Till exempel kan knappen Skicka för ett formulär inaktiveras om det finns en kontroll som har ett valideringsfel i formuläret.

Vi rekommenderar att du använder den anpassade felmallen som finns i formulärinfrastrukturbiblioteket. Om en kontroll har ett valideringsfel visas den som standard med en röd omgivande kant. WPF gör det möjligt att definiera en anpassad felindikator via egenskapen Validation.ErrorTemplate , som kan anges för alla kontroller. Infrastrukturbiblioteket Service Manager formulär innehåller en anpassad felmall som visar en felikon i stället för den röda WPF-kantlinjen. Dessutom visas en knappbeskrivning tillsammans med ett felmeddelande när en användare pekar med musen på felikonen. Felmeddelandet ska ange skälet till att data i kontrollen inte godkändes vid valideringen.

I följande exempel visas hur du refererar till felmallen i XAML:

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

Om de inbyggda valideringsreglerna inte tillhandahåller den valideringslogik som krävs rekommenderar vi att du skapar anpassade verifieringsregler som representerar den logiken. Det gör det möjligt för standardenlig och anpassad valideringslogik att samexistera med den gemensamma hanteringsmekanismen för validering.

Om mekanismen för valideringsregler inte är lämplig för ett visst scenario bör du i stället hantera FormEvents.PreviewSubmitEvent och köra valideringen därifrån.

I följande kodexempel visas ett exempel på mönstret som du kan använda när du kör en anpassad validering:

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
}

Använda kommandon och händelser för formulärinfrastruktur

Formulärinfrastrukturen exponerar ett antal kommandon som kan köras på ett formulär. Dessa kommandon omfattar:

• FormsCommand.Submit, som sparar målinstansen av formuläret.

• FormsCommand.SubmitAndClose, som sparar målinstansen av formuläret och stänger formuläret.

• FormsCommand.Refresh, som upprepar frågan för målinstansen av formuläret.

• FormCommands.Cancel, som tar bort alla ändringar och stänger formuläret.

Varje enskilt kommando omges av händelser, som aktiveras före och efter att kommandot körs.

Före kommandot aktiveras följande händelser:

• Händelsen FormEvents.PreviewSubmit utlöses före kommandot FormCommand.Submit och händelsen FormEvents.Submitted utlöses efter kommandot FormCommand.Submit .

• Händelsen FormEvents.PreviewRefreshutlöses före kommandot FormCommands.Refresh och kommandot FormCommand.Refreshed utlöses efter kommandot FormCommand.Submit .

• Händelsen FormEvents.PreviewCancelutlöses före kommandot FormCommands.Cancel och händelsen FormCommand.Canceled utlöses efter kommandot FormCommand.Cancel .

Förhandsgranskningshändelserna skickar ett PreviewFormCommandEventArgs-objekt . Det här objektet innehåller en föränderlig Cancel-egenskap som förhindrar att motsvarande kommando körs när egenskapen är inställd på true.

Händelser efter kommandot skickar ett FormCommandExecutedEventArgs-objekt . Det här objektet innehåller egenskapen Result som anger om körningen av kommandot lyckades, avbröts eller orsakade ett fel. Om det uppstår ett fel refererar error-egenskapen för objektet FormCommandExecutedEventArgs till undantaget som innehåller information om felet.

Det går att aktivera, inaktivera och köra formulärkommandon såväl programmässigt som deklarativt.

Om du vill aktivera formulärkommandon programmatiskt upprättar du en CommandBinding mellan formuläret och det relaterade kommandot.

I följande exempel upprättas en kommandobindning mellan formuläret och ett Refresh-kommando , och två hanterare definieras för det här kommandot. Den första hanteraren returnerar om kommandot Uppdatera kan köras och den andra hanteraren innehåller implementeringen av kommandot Uppdatera:

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

Du kan också definiera hanterare för formulärkommandon deklarativt. Du kan göra detta genom att använda ett regelobjekt som använder en RoutedCommandTrigger. I följande kodexempel visas hur hanterare definieras deklarativt:

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

Nästa steg

• Anpassa och skapa formulär med Service Manager Authoring Tool.
• Anpassa standardincidentformuläret för redigeringsverktygets exempelscenario.