Übersicht über das Anpassen und Erstellen von Formularen mit dem Service Manager Authoring Tool
Wichtig
Diese Version von Service Manager das Ende des Supports erreicht hat, wird empfohlen, ein Upgrade auf Service Manager 2019durchzuführen.
Ein Formular ist ein Fenster, in dem Benutzer mit Objekten der Datenbank interagieren können. Benutzer können Eigenschaften von Objekten in einem Formular anzeigen und bearbeiten. Jedes Formular ist an eine bestimmte Klasse gebunden und zeigt nur Informationen für Instanzen der Zielklasse an. Ein Formular enthält Felder. In der Regel ist jedes Feld an eine bestimmte Eigenschaft der Zielklasse des Formulars gebunden. Das Incidentformular ist z. B. an das Incidentobjekt gebunden. Daher zeigt das Incidentformular Informationen zu Incidentobjekten in der Datenbank an.
Ein Service Manager Formular besteht aus der Windows Presentation Foundation -Formularimplementierung (WPF) in einer Microsoft .NET Framework-Assembly und einer Formulardefinition in einem Service Manager Management Pack. Die Formulardefinition legt die vom Formular dargestellte Klasse fest, zusammen mit den anderen Eigenschaften des Formulars.
Wichtige Konzepte zu Formularen
Vor dem Anpassen von Formularen sollten Sie mit der folgenden Formularkonzepten vertraut sein.
Verwendung von Formularen
Wenn das Management Pack, das die Formulardefinitionen enthält, in Service Manager importiert wird, werden die Formulardefinitionen in der Datenbank gespeichert. Wenn der Benutzer später eine Service Manager Konsolenaufgabe initiiert, die die Anzeige eines Objekts erfordert, muss Service Manager ein Formular finden, um das angeforderte Objekt anzuzeigen. Service Manager greift auf die Datenbank zu und sucht nach einem Formular, das für dieses Objekt definiert wurde. Wenn kein Formular für das Objekt definiert ist, sucht Service Manager nach einem Formular, das für das übergeordnete Objekt des Objekts definiert ist. Service Manager durchsucht weiterhin die Vererbungshierarchie des gesamten Objekts, bis ein definiertes Formular gefunden wird.
Generische Formulare
Wenn Service Manager keine Form für das Objekt oder für eines seiner übergeordneten Objekte finden können, erstellt Service Manager dynamisch ein generisches Standardformular für dieses Objekt. Beim generischen Formular handelt es sich um ein vom System generiertes Formular, das für die einfache Formularnutzung ausreicht. Das generische Formular stellt eine schnelle und einfache Möglichkeit zum Erstellen eines Formulars für Objekte ohne Formulardefinitionen dar.
Vom generischen Formular werden alle Eigenschaften des Formulars in einem einfachen Layout dargestellt, das nicht geändert werden kann. Vom generischen Formular werden die Eigenschaften aller übergeordneten Objekte in der Vererbungshierarchie des Formulars dargestellt. Dieses Verhalten kann nicht geändert werden. Das generische Formular kann nur eingeschränkt angepasst werden. Sie können beispielsweise die Eigenschaften festlegen, die vom generischen Formular angezeigt werden sollen. Das generische Formular kann jedoch nicht als Basis für Anpassungen verwendet werden. Wenn Sie später ein benutzerdefiniertes Formular für dieses Objekt definieren, überschreibt Das benutzerdefinierte Formular das generische Formular des Objekts.
Informationen zum Ausblenden von Eigenschaften in einem generischen Formular sowie zu anderen Möglichkeiten zum Anpassen eines generischen Formulars finden Sie im Blogpost Overview of the Forms Infrastructure and the Generic Form (Übersicht über die Formularinfrastruktur und das generische Formular).
Kombinationsklassen in Formularen
Gelegentlich benötigen Sie ein Formular zum Anzeigen von Informationen, die aus mehreren Klassen abgeleitet werden. Hierzu erstellen Sie eine Kombinationsklasse , und dann binden Sie ein Feld im Formular an die Kombinationsklasse. Weitere Informationen zu Kombinationsklassen finden Sie unter Änderungen am System Center Common Schema.
Funktionale Aspekte eines Formulars
Ein Formular weist folgende funktionalen Aspekte auf:
Initialisierung
Größe und Speicherort
Aktualisieren
Änderungen senden
Diese Aspekte werden in den folgenden Abschnitten beschrieben.
Initialisierung
Während der Initialisierung wird die Extensible Application Markup Language (XAML) eines Formulars analysiert, und alle Steuerelemente im Formular werden instanziiert und geladen. Das Loaded-Ereignis des Formulars gibt an, wann das Formular und alle enthaltenen Elemente geladen wurden. Datenladevorgänge werden asynchron ausgeführt. Daher ist die Zielinstanz möglicherweise nicht verfügbar, wenn das Ereignis Loaded ausgelöst wird. Stattdessen muss das Ereignis DataContextChanged für Benachrichtigungen verwendet werden, wenn die Zielinstanz für das Formular festgelegt wird. Das Ereignis PropertyChanged für die Eigenschaft DataContext kann anstelle des Ereignisses DataContextChanged verwendet werden.
Es wird empfohlen, das Ereignis Loaded für die angepasste Initialisierung von Steuerelementen und anschließend das Ereignis DataContextChanged oder das Ereignis PropertyChanged für die Eigenschaft DataContext für die angepasste Initialisierung von Zielinstanzen zu verwenden.
Größe und Speicherort
Wenn ein Formular in einem Popupfenster angezeigt wird, wird seine Anfangsgröße basierend auf den Eigenschaften Width,Height,MinWidthund MinHeight des Formulars bestimmt. Wenn diese Eigenschaften nicht für das Formular festgelegt sind, wird die Anfangsgröße des Formulars basierend auf seinem Inhalt berechnet.
Es wird empfohlen, diese Eigenschaften wie folgt festzulegen:
Legen Sie die Eigenschaften Width und Height des Formulars explizit auf die optimale Größe fest. Legen Sie für diese Einstellungen am besten den Wert Auto fest. Damit wird die Breite und Höhe des Formulars basierend auf der Größe des Inhalts festgelegt.
Legen Sie die Eigenschaften MinWidth und MinHeight des Formulars auf die für das Formular kleinste akzeptable Fenstergröße fest. Wenn das Fenster von einem Benutzer auf eine kleinere Größe als die angegebene Größe verkleinert wird, werden Bildlaufleisten angezeigt, mit deren Hilfe der verborgene Formularinhalt angezeigt werden kann.
Wenn das Formular innerhalb des Service Manager Formularhosts gehostet wird, werden die zuletzt verwendete Größe und der zuletzt verwendete Speicherort für die nachfolgende Anzeige dieses Formulars durch denselben Benutzer innerhalb derselben Ausführungssitzung beibehalten.
Aktualisieren
Die Zielinstanz kann sich aufgrund der Ausführung eines Befehls vom Typ Refresh für das Formular ändern. Vom Handler für diesen Befehl werden neue Daten aus der Datenbank abgerufen. Wenn die Daten eintreffen, wird der DataContext-Eigenschaftswert des Formulars auf die neue Zielinstanz festgelegt, und das DataContextChanged-Ereignis wird ausgelöst.
Für die Unterscheidung zwischen dem Ereignis DataContextChanged , das beim ersten Laden des Formulars ausgelöst wurde, und dem Ereignis, das zum Behandeln eines Befehls vom Typ Refresh ausgelöst wurde, prüfen Sie die Eigenschaft OldValue der mit dem Ereignis übergebenen Ereignisargumente. Diese Eigenschaft ist null, wenn das Formular nur initialisiert wurde.
Änderungen senden
Das Popupfenster des Formularhosts in Service Manager enthält Schaltflächen zum Übermitteln von Änderungen, die im Formular vorgenommen werden, und zum Schließen des Popupfensters.
Wenn ein Benutzer auf die Schaltfläche Anwenden für ein Formular klickt, wird die Zielinstanz des Formulars zur Speicherung übermittelt. Dieser Vorgang wird synchron ausgeführt. Daher kann der Benutzer das Formular erst nach Abschluss des Sendevorgangs bearbeiten. Wenn während der Übermittlung des Formulars Fehler auftreten, wird eine Fehlermeldung angezeigt. Das Formular bleibt für weitere Änderungen geöffnet. Es wird empfohlen, dass Benutzer ihre Änderungen regelmäßig übernehmen, um Kollisionen zu vermeiden, wenn gleichzeitig eine andere Instanz des Formulars bearbeitet wird.
Wenn der Benutzer auf die Schaltfläche OK klickt, ist das Verhalten ähnlich wie beim Klicken auf die Schaltfläche Übernehmen, jedoch mit dem Unterschied, dass das Formular und das entsprechende Hostfenster bei erfolgreichem Senden des Formulars geschlossen werden.
Wenn der Benutzer auf die Schaltfläche Abbrechen klickt, wird ein Dialogfeld angezeigt, mit dem der Benutzer aufgefordert wird, den Vorgang zu bestätigen. Wenn der Benutzer auf Ja klickt, gehen Änderungen verloren. Er kann auch auf Nein klicken, um zum Formular zurückzukehren.
Allgemeine Richtlinien und bewährte Methoden für Formulare
Sie können Features von Service Manager erweitern, indem Sie Formulare hinzufügen oder ändern. In diesem Thema werden einige Empfehlungen zu bewährten Methoden zum Erstellen und Verwenden von Service Manager Formularen beschrieben, wobei verschiedene Tools und Formulardefinitionen direkt skriptt werden.
Dieses Thema ist in erster Linie für Partner und Kunden bestimmt, die Erfahrung im Erstellen von eigenen benutzerdefinierten Formularen mithilfe von Windows Presentation Foundation (WPF) und Microsoft Visual Studio Team System oder Microsoft Expression Blend haben.
Die allgemeinen Richtlinien für das Erstellen eines neuen Formulars lauten wie folgt.
- Verwenden Sie Standardsteuerelemente.
- Befolgen Sie allgemeine Richtlinien für den Formularentwurf.
- Vermeiden Sie CodeBehind.
- Beziehen Sie Ausnahmebehandlung mit ein.
- Berücksichtigen Sie Formularanpassungen und Formularupgrades.
- Benennen Sie alle anpassbaren Steuerelemente.
- Binden Sie das Formular an Datenquellen.
- Verwenden Sie Service Manager Formularinfrastruktur-Validierungsregeln, Wertkonverter und Fehlervorlagen.
- Verwenden Sie Befehle und Ereignisse der Formularinfrastruktur.
Informationen zu diesen Richtlinien finden Sie in folgenden Abschnitten.
Verwenden von Standardsteuerelementen
Folgende Steuerelemente können in einem Formular verwendet werden:
- Standardsteuerelemente. Hierzu gehören Steuerelemente der .NET-Bibliothek, z. B. Kombinationsfeld und Listenfeld.
- Benutzerdefinierte Steuerelemente. Hierzu zählen weitere Steuerelemente, die vom Formularautor oder einem Dritten erstellt werden.
Tipp
Wenn Sie möglichst immer Standardsteuerelemente verwenden und die Erstellung benutzerdefinierter Steuerelemente vermeiden, fördern Sie die Konsistenz im Hinblick auf die Benutzerfreundlichkeit von Formularen. Wenn Sie ein benutzerdefiniertes Steuerelement erstellen müssen, trennen Sie die visuelle Darstellung und das Verhalten vom logischen Verhalten, indem Sie zum Definieren der Darstellung des Steuerelements Steuerelementvorlagen verwenden. Vorzugsweise sollte für jedes Windows-Design eine separate Steuerelementvorlage vorhanden sein.
Befolgen allgemeiner Entwurfsrichtlinien für Formulare
Stellen Sie beim Entwurf eines Formulars mithilfe von öffentlichen Entwurfsrichtlinien sicher, dass das Formular benutzerfreundlich ist und allgemeinen Paradigmen für den Benutzereingriff entspricht.
Weitere Informationen zu allgemeinen Windows-Designs finden Sie unter Windows User Experience Interaction Guidelines (Richtlinien für den Eingriff durch Windows-Benutzer).
Zusätzlich:
- Verteilen Sie Informationen auf mehrere Registerkarten, damit das Formular einfacher zu lesen ist. Fügen Sie die am häufigsten verwendeten Informationen auf der ersten Registerkarte und weniger wichtige Informationen auf nachfolgenden Registerkarten ein.
- Verwenden Sie Layoutbereiche, um Steuerelemente auf dem Formular anzuordnen. Dadurch wird sichergestellt, dass sich das Formular ordnungsgemäß verhält, wenn die Größe des Formulars angepasst und das Formular lokalisiert wird.
- Vermeiden Sie es, für visuelle Eigenschaften einzelne Steuerelemente festzulegen. Verwenden Sie stattdessen Formatvorlagen. Auf diese Weise können Sie die Darstellung aller Steuerelemente in mehreren Formularen ändern, indem Sie die Formatvorlage ändern. So fördern Sie eine konsistente Darstellung in allen verwandten Formularen.
Vermeiden von CodeBehind
CodeBehind ist ein Ausdruck, mit dem der Code beschrieben wird, der beim Ausführen der Markupkompilierung für eine XAML-Seite mit Markup-definierten Objekten verknüpft wird. Sie sollten die Verwendung von CodeBehind in Formularen so weit wie möglich beschränken. Besser ist es, den Code für ein Formular in das Steuerelement einzubetten, da es leichter ist, später diesen Code zu ändern. Verwenden Sie stattdessen die deklarativen Funktionen, die von der Service Manager Formularinfrastruktur unterstützt werden, um Wertkonvertierungen und Validierungsregeln im Formular zu definieren.
Generell sollten Sie die Verwendung von CodeBehind auf Situationen beschränken, in denen es nicht möglich ist, die erforderliche Funktionalität mithilfe der Deklarationsfunktionen von XAML mit in WPF definierten Klassen und der Bibliothek der Formularinfrastruktur bereitzustellen. Selbst dann sollten Sie die in CodeBehind implementierte Funktionalität in eine Hilfsbibliothek verschieben und dann im XAML-Code darauf verweisen.
Einschließen der Ausnahmebehandlung
Stellen Sie sicher, dass der Code im Formular die Ausnahmebehandlung enthält, damit das Formular sowohl während der Entwurfsphase im Authoring Tool als auch zur Laufzeit in der Service Manager-Konsole geladen werden kann.
Ziehen Sie Anpassungen und Upgrades von Formularen in Betracht.
Beim Entwerfen eines neuen Formulars sollten Sie künftige Anpassungen und Upgrades für dieses Formular berücksichtigen. Befolgen Sie die Richtlinien und Tipps weiter oben in diesem Abschnitt sowie folgende Richtlinien, um sicherzustellen, dass ein Formular angepasst und ein Upgrade unter Beibehaltung von Anpassungen ausgeführt werden kann:
Berücksichtigen Sie zukünftige Anpassungen und Aktualisierungen frühzeitig beim Entwerfen des Formulars. Formulare werden in zukünftigen Versionen weiterentwickelt. Daher ist es wichtig zu berücksichtigen, dass Benutzer unter Beibehaltung ihrer Anpassungen des ursprünglichen Formulars ein Upgrade auf neuere Versionen des Formulars ausführen können. So kann es beispielsweise vorkommen, dass Sie ein aktualisiertes Formular bereitstellen, nachdem Benutzer das ursprüngliche Formular umfangreich angepasst haben. Benutzer erwarten, dass ihre Anpassungen beim Versionsupgrade beibehalten werden.
Geben Sie für jedes Steuerelement im Formular einen eindeutigen Namen an, damit Anpassungen auf Steuerelemente angewendet werden können. Formularanpassungen werden in Form von Aktionen gespeichert, die von einem bestimmten Steuerelement oder von einem bestimmten Satz Steuerelemente als Ziel verwendet werden. Das Zielsteuerelement wird anhand des Namens referenziert. Daher ist es wichtig, dass die Namen von Steuerelementen in allen Versionen des Formulars erhalten bleiben. Wenn ein Steuerelement keinen Namen hat, wird vom Formularanpassungs-Editor ein Name generiert. Der generierte Name wird jedoch in den verschiedenen Versionen des Formulars nicht beibehalten.
Stellen Sie sicher, dass Steuerelementnamen in verschiedenen Versionen des Formulars unveränderlich bleiben. Dadurch wird sichergestellt, dass Anpassungen für ein bestimmtes Steuerelement einer früheren Version auf dasselbe Steuerelement in einer neueren Version des Formulars angewendet werden können.
Wenn möglich, sollten Sie beim Ausführen eines Upgrade für ein Formular vermeiden, Steuerelemente auf einer Registerkarte an eine andere Position zu verschieben. Benutzer nehmen häufig die Anpassung vor, dass sie Steuerelemente auf dem Formular an eine andere Position verschieben. Wenn Sie die Position eines Steuerelements in einer neuen Version des Formulars ändern, besteht die Gefahr, dass sich die neue Position des Steuerelements mit einem Steuerelement überschneidet, dem vom Benutzer eine neue Position zugewiesen wurde.
Wenn möglich, sollten Sie beim Entwerfen eines Updates für ein vorhandenes Formular vermeiden, Steuerelemente zwischen Registerkarten zu verschieben. Steuerelemente werden anhand des Namens und anhand der Registerkarte, auf der sie sich befinden, identifiziert. Wenn ein Steuerelement von einer Registerkarte auf eine andere Registerkarte in der neuen Version des Formulars verschoben wird, können die vom Benutzer an diesem Steuerelement vorgenommenen Anpassungen unterbrochen werden, da das Zielsteuerelement von den Anpassungen nicht identifiziert werden kann.
Wenn die Aktualisierung eines Formulars neue Steuerelemente enthält, sollten Sie erwägen, die neuen Steuerelemente einer neuen Registerkarte hinzuzufügen. Dies ist die sicherste Möglichkeit, benutzerspezifische Anpassungen an den vorhandenen Registerkarten und Steuerelementen zu vermeiden.
Berücksichtigen Sie wie die Steuerelemente gebunden werden. Für schreibgeschützte Steuerelemente sollten nur unidirektionale Bindungen verwendet werden.
Benennen aller anpassbaren Steuerelemente
Stellen Sie sicher, dass mit den Steuerelementnamen beschrieben wird, an welche Daten das Steuerelement gebunden wurde oder was das Steuerelement bewirkt.
Binden des Formulars an Datenquellen
Der Hauptzweck eines Formulars besteht darin, ein einzelnes Objekt aus der Service Manager Datenbank zu visualisieren. Dieses Objekt wird als target instancebezeichnet, die immer von der Eigenschaft DataContext eines Formulars angegeben wird (die von der Klasse FrameworkElement vererbt wird).
Wichtig
Ändern Sie die DataContext-Eigenschaft des Formulars nicht. In der Formularhostumgebung wird diese Eigenschaft zum Identifizieren der Formularzielinstanz verwendet.
Im Service Manager Datenmodell wird eine Zielinstanz als BindableDataItem-Objekt dargestellt. Von dieser Klasse wird das zugrunde liegende SDK-Objekt (Software Development Kit) aggregiert. Zudem macht sie ihre Eigenschaften über einen Indexer verfügbar, von dem ein Eigenschaftsname als Parameter angenommen wird.
Von der Klasse BindableDataItem wird auch ICustomTypeDescriptorimplementiert. Dadurch kann die Klasse BindableDataItem als Datenquelle für die WPF-Bindung verwendet werden. Im folgenden Beispiel ist die Bindung einer Zielinstanzeigenschaft an die Eigenschaft Text eines Steuerelements vom Typ TextBox dargestellt:
<TextBox Name="textBoxDescription" Text="{Binding Path=Summary}"/>
Die Source der Bindung muss nicht angegeben werden, da die Zielinstanzen als DataContext des Formulars festgelegt werden, der als Standard- Source für alle Steuerelemente im Formular dient.
Steuerelemente im Formular können an andere Datenquellen als an die Zielinstanz gebunden werden, und die Bibliothek der Formularinfrastruktur enthält Steuerelemente, von denen die Bindung implizit ausgeführt wird. Das Steuerelement zur Auswahl einer Instanz ist beispielsweise an die Datenquelle gebunden, von der die Sammlung mit Instanzen zur Auswahl bereitgestellt wird. Darüber hinaus ist es möglich, mithilfe der Klassen ObjectDataProvider und XmlDataProvider weitere Daten deklarativ zu definieren.
Von der Formularinfrastruktur wird die Zielinstanz als die einzige Lese-/Schreib-Datenquelle im Formular erkannt. Daher werden bei der Implementierung des Befehls Submit nur die an der Zielinstanz vorgenommenen Änderungen gespeichert. Andere Datenquellen des Formulars werden wie schreibgeschützte Datenquellen behandelt.
Verwenden Service Manager Formularinfrastrukturvalidierungsregeln, Wertkonverter und Fehlervorlagen
Es wird empfohlen, in Formularen Gültigkeitsprüfungsregeln der Formularinfrastruktur zu verwenden, um ungültige Dateneingaben zu bestimmen. Von der WPF-Bindungsinfrastruktur wird die Gültigkeitsprüfung für Steuerelementeigenschaften unterstützt, die über eine unidirektionale oder bidirektionale Bindung an eine Datenquelle gebunden sind. Das Bindungsobjekt verfügt über eine Sammlung vom Typ ValidationRules , die eine beliebige Anzahl von Objekten vom Typ ValidationRule enthalten kann. Wenn Daten mithilfe von Push vom Steuerelement an die Datenquelle übertragen werden, werden die Objekte vom Typ ValidationRule zur Gültigkeitsprüfung des Werts aufgerufen.
Die Bibliothek der Formularinfrastruktur enthält mehrere Gültigkeitsprüfungsregeln für die meisten gängigen Fälle. Von der Formularinfrastruktur werden die Gültigkeitsprüfungsregeln verwendet, um zu ermitteln, ob die Formularinhalte zum Speichern übermittelt werden können. Beispielsweise kann die Schaltfläche Senden eines Formulars deaktiviert werden, wenn ein Steuerelement mit einem Validierungsfehler im Formular vorhanden ist.
Es wird empfohlen, die mit der Bibliothek der Formularinfrastruktur bereitgestellte benutzerdefinierte Fehlervorlage zu verwenden. Wenn ein Steuerelement einen Überprüfungsfehler aufweist, wird es standardmäßig mit einem roten Rahmen angezeigt. Mithilfe von WPF kann über die Eigenschaft Validation.ErrorTemplate ein benutzerdefinierter Fehlerindikator definiert werden, der für jedes Steuerelement festgelegt werden kann. Die Service Manager Forms-Infrastrukturbibliothek enthält eine benutzerdefinierte Fehlervorlage, die anstelle des roten WPF-Rahmens ein Fehlersymbol anzeigt. Zudem wird eine QuickInfo mit einer Fehlermeldung angezeigt, wenn der Benutzer mit der Maus auf das Fehlersymbol zeigt. In der Fehlermeldung sollte der Grund dafür angegeben werden, warum bei der Gültigkeitsprüfung der Daten im Steuerelement ein Fehler aufgetreten ist.
Mit dem folgenden Beispiel wird gezeigt, wie die Fehlervorlage in XAML referenziert wird:
<TextBox Text="{Binding SomeProperty}"
scwpf:Validation.ValueRequired="True"
Validation.ErrorTemplate="{DynamicResource {ComponentResourceKey {x:Type scwpf:Validation}, InvalidDataErrorTemplate}}"/>
Wenn von den integrierten Gültigkeitsprüfungsregeln nicht die erforderliche Gültigkeitsprüfungslogik bereitgestellt wird, wird empfohlen, benutzerdefinierte Gültigkeitsprüfungsregeln zur Darstellung dieser Logik zu erstellen. So können im allgemeinen Mechanismus zur Behandlung von Gültigkeitsprüfungen gleichzeitig eine Standardgültigkeitsprüfungslogik und eine benutzerdefinierte Gültigkeitsprüfungslogik vorhanden sein.
Wenn der Mechanismus mit den Gültigkeitsprüfungsregeln für ein bestimmtes Szenario nicht geeignet ist, sollten Sie stattdessen FormEvents.PreviewSubmitEvent behandeln und die Gültigkeitsprüfung von dort ausführen.
Der folgende Code ist ein Beispiel für das Muster, das Sie verwenden können, um eine benutzerdefinierte Gültigkeitsprüfung auszuführen:
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
}
Verwenden von Formularinfrastrukturbefehlen und -ereignissen
Von der Formularinfrastruktur werden Befehle angezeigt, die in einem Formular ausgeführt werden können. Folgende Befehle sind verfügbar:
FormsCommand.Submit: Mit diesem Befehl wird die Zielinstanz des Formulars gespeichert.
FormsCommand.SubmitAndClose: Mit diesem Befehl wird die Zielinstanz des Formulars gespeichert und das Formular geschlossen.
FormsCommand.Refresh: Mit diesem Befehl wird die Abfrage für die Zielinstanz des Formulars wiederholt.
FormCommands.Cancel: Mit diesem Befehl werden alle Änderungen verworfen und das Formular geschlossen.
Jeder dieser Befehle wird von Ereignissen umschlossen, die vor und nach der Ausführung des Befehls ausgelöst werden.
Vor dem Befehl werden folgende Ereignisse ausgelöst:
Das Ereignis FormEvents.PreviewSubmit wird vor dem Befehl FormCommand.Submit ausgelöst, während das Ereignis FormEvents.Submitted nach dem Befehl FormCommand.Submit ausgelöst wird.
Das Ereignis FormEvents.PreviewRefresh wird vor dem Befehl FormCommands.Refresh ausgelöst, während der Befehl FormCommand.Refreshed nach dem Befehl FormCommand.Submit ausgelöst wird.
Das Ereignis FormEvents.PreviewCancel wird vor dem Befehl FormCommands.Cancel ausgelöst, während das Ereignis FormCommand.Canceled nach dem Befehl FormCommand.Cancel ausgelöst wird.
Mit den Ereignissen vom Typ „preview“ wird ein Objekt vom Typ PreviewFormCommandEventArgs übergeben. Dieses Objekt enthält eine änderbare Eigenschaft vom Typ Cancel , mit der verhindert wird, dass der entsprechende Befehl ausgeführt wird, wenn die Eigenschaft auf truefestgelegt ist.
Mit den nach dem Befehl ausgeführten Ereignissen wird ein Objekt vom Typ FormCommandExecutedEventArgs übergeben. Dieses Objekt enthält eine Eigenschaft vom Typ Result , mit der angegeben wird, ob der Befehl erfolgreich ausgeführt, ob er abgebrochen, oder ob durch ihn ein Fehler verursacht wurde. Wenn durch ihn ein Fehler verursacht wurde, wird von der Eigenschaft Error des Objekts FormCommandExecutedEventArgs auf die Ausnahme mit Informationen zum Fehler verwiesen.
Formularbefehle können sowohl programmgesteuert als auch deklarativ aktiviert, deaktiviert und ausgeführt werden.
Richten Sie zum programmgesteuerten Aktivieren von Formularbefehlen eine CommandBinding zwischen dem Formular und dem entsprechenden Befehl ein.
Im folgenden Beispiel wird eine Befehlsbindung zwischen dem Formular und einem Befehl vom Typ Refresh eingerichtet. Zudem werden zwei Handler für diesen Befehl definiert. Mit dem ersten Handler werden Informationen dazu zurückgegeben, ob der Befehl Refresh ausgeführt werden kann. Der zweite Handler enthält die Implementierung des Befehls Refresh :
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
}
}
Handler für Formularbefehle können auch deklarativ definiert werden. Verwenden Sie hierzu ein Objekt vom Typ Rule , von dem ein RoutedCommandTriggerverwendet wird. Mit dem folgenden Codebeispiel wird gezeigt, wie Handler deklarativ definiert werden:
<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>