Empfohlene Methoden für die Entwicklung von TestStand-Benutzeroberflächen

TestStand basiert auf einer modularen Architektur mit eigenständigen Komponenten, die jeweils einen Zweck erfüllen, was die Entwicklung und Wartung des gesamten Systems einfacher macht.

Die Benutzeroberfläche ist eine eigenständige Komponente innerhalb der modularen TestStand-Architektur

Mit der Benutzeroberflächenkomponente können Entwickler und Testbetreiber Sequenzen in einem Testsystem erstellen und ausführen. In einer modularen Architektur sollte eine klare Grenze zwischen der Benutzeroberfläche und der zugrunde liegenden TestStand-Anwendung bestehen. Das bietet die folgenden Vorteile:

• Nahtlose Interaktion mit einem Testsystem über mehrere verschiedene Benutzeroberflächen.  Beispielsweise können Testentwickler den Sequence Editor verwenden, um Sequenzen zu entwickeln, während Testbetreiber eine Bedienoberfläche verwenden, um Tests auszuführen und Ergebnisse anzuzeigen.
• Änderungen an der Benutzeroberfläche, ohne dass das Verhalten des Tests selbst geändert wird.

TestStand-Benutzeroberflächen kommunizieren mit der TestStand Engine-API, um ihre verschiedenen Funktionen auszuführen, z. B. den Status der Testausführungen abzurufen, Sequenzen zu erstellen und zu bearbeiten sowie Einstellungen zu konfigurieren. TestStand bietet zudem eine Reihe von Bedienelementen für die Benutzeroberfläche und eine separate UI-API, mit der Sie schnell Ihre eigenen TestStand-Benutzeroberflächen erstellen können.

Elemente der Benutzeroberfläche (UI) in TestStand

Die Elemente der TestStand-Benutzeroberfläche bestehen aus einer Reihe von ActiveX-Elementen, mit denen die allgemeinen Funktionen implementiert werden, die von Anwendungen für die Anzeige und Ausführung von Testsequenzen sowie für die Fehlersuche benötigt werden. Mit diesen ActiveX-Elementen ist wesentlich weniger Quellcode erforderlich, damit eine Benutzeroberfläche mit der TestStand-API interagieren und Benutzeroberflächenaufgaben erledigen kann. Sie können die Eigenschaftenseiten verwenden oder die verfügbaren Eigenschaften und Methoden aufrufen, um diese Steuerelemente zu konfigurieren. Im Hilfethema zu TestStand-UI-Elementen finden Sie weitere Informationen zur Verwendung der Teststand-UI-Elemente in LabVIEW, CVI, C# oder VB.NET.

Manager-Bedienelemente und sichtbare Bedienelemente

Die TestStand-UI-Elemente bieten zwei Sätze von Bedienelementen für die Benutzeroberfläche: Manager-Bedienelemente und sichtbare Bedienelemente.

Mit den Manager-Elementen wird die TestStand-API aufgerufen, um Tasks wie das Laden von Dateien, das Starten von Ausführungen und das Abrufen von Sequenz- und Ausführungsinformationen auszuführen. Manager-Elemente dienen außerdem zur Benachrichtigung, wenn Anwendungsereignisse auftreten, wie z. B. bei der Anmeldung eines Benutzers, beim Erreichen eines Haltepunkts einer Anwendung oder beim Ändern der angezeigten Datei oder Sequenz durch einen Benutzer. Manager-Elemente sind zur Laufzeit nicht sichtbar.

Sichtbare Bedienelemente zeigen Benutzern Informationen an, wie ein Bedienelement für die Ausführungsansicht, das den aktuellen Ausführungsstatus anzeigt. Über sichtbare Bedienelemente können Benutzer zudem mit der Benutzeroberfläche interagieren. Sie können z. B. einen Test über ein Schaltflächenelement ausführen.  Sichtbare Bedienelemente müssen mit einem Manager-Element verbunden sein, um zu definieren, wie sie funktionieren.  Diese Verbindung wird mithilfe der Verbindungsmethoden der Manager-Elemente implementiert. Wenn Sie Bedienelemente verbinden, wird die interne Logik für das Verhalten des sichtbaren Bedienelements automatisch von den Manager-Elementen verarbeitet.  Abhängig von der Art des Manager-Elements und des zu verbindenden sichtbaren Bedienelements und der benötigten Funktionsweise können Sie Ansichtsverbindungen, Listenverbindungen, Befehlsverbindungen und Verbindungen zur Informationsquelle herstellen.

Verbinden Sie sichtbare TestStand-UI-Elemente mit Manager-Elementen, um Funktionsweisen zu definieren.

Weitere Informationen zur Verwendung der TestStand-UI-Elemente in verschiedenen Programmierumgebungen finden Sie im Hilfethema Elemente der Benutzeroberfläche in TestStand.  Sie können auch die Demo zum Verbinden von UI-Elementen verwenden, um das Verhalten der verfügbaren Verbindungen anzuzeigen, die Sie erstellen können.

Darüber hinaus können Sie die in Ihrer Programmierumgebung nativ bereitgestellten Bedienelemente neben den TestStand-UI-Elementen verwenden. Wenn Sie mit programmeigenen Bedienelementen arbeiten, können Sie mithilfe der Benutzeroberflächen-API direkt mit den Manager-Elementen kommunizieren, um TestStand-bezogene Funktionen zu implementieren. Weitere Informationen zum Schreiben einer Anwendung, die die TestStand-API direkt aufruft, finden Sie im Beispiel zum Building a TestStand UI with Native Controls.

Einfache und Full-Featured-Beispielanwendungen für Benutzeroberflächen

TestStand stellt verschiedene Beispiele und Komponenten bereit, mit denen Sie eine Benutzeroberfläche erstellen können. Die Beispielbenutzeroberflächen bieten einen Ausgangspunkt für die Entwicklung einer benutzerdefinierten Benutzeroberfläche. TestStand wird außerdem mit Benutzeroberflächenkomponenten geliefert, die allgemeine Funktionen implementieren, die in diesen Anwendungen verwendet werden und die Sie in Ihren eigenen Anwendungen wiederverwenden können.

TestStand wird mit Anwendungsbeispielen (einfach sowie mit vollem Funktionsumfang) für die Benutzeroberfläche in unterstützten Programmiersprachen geliefert, darunter LabVIEW, Labwindows™/CVI™, C# und VB.net. TestStand stellt Quellcode für diese Beispiele in jeder der unterstützten Programmiersprachen bereit. Sie können diesen Quellcode als Ausgangspunkt für die Entwicklung einer benutzerdefinierten Benutzeroberfläche verwenden oder unverändert nutzen.

Die einfache Benutzeroberfläche verfügt über eine minimale Anzeige, enthält keine Menüleiste und ist als Oberfläche für Testbetreiber auf einem bereitgestellten Testsystem gedacht. Die Full-Featured-Benutzeroberfläche zeigt weitere Informationen an, enthält eine Menüleiste und bietet Funktionen für die Fehlerbehandlung.  Die Full-Featured-Benutzeroberfläche verfügt zudem über einen Editor-Modus, mit dem Sie Testsequenzen erstellen und ändern können, wie den TestStand Sequence Editor.

Die einfachen Benutzeroberflächenbeispiele stellen einen guten Ausgangspunkt dar, um die Entwicklung mit den TestStand-UI-Elementen zu erlernen.  Für die LabVIEW-, LabWindows/CVI- oder C#-Implementierungen finden Sie in den folgenden Leitfäden eine detaillierte Beschreibung des Quellcodes und seiner Funktionsweise:

• Working with the TestStand Simple User Interface - LabVIEW (Arbeiten mit der einfachen TestStand-Benutzeroberfläche – LabVIEW)
• Working with the TestStand Simple User Interface - LabWindows/CVI (Arbeiten mit der einfachen TestStand-Benutzeroberfläche – LabWindows/CVI)
• Working with the TestStand Simple User Interface - C#.NET (Arbeiten mit der einfachen TestStand-Benutzeroberfläche – C#.NET)

Bei der Entwicklung von Benutzeroberflächen für ein Testsystem müssen Sie die Ziele und Anforderungen aller Benutzer berücksichtigen, die mit der Anwendung interagieren.  Benutzer von Testsystemen können in der Regel in die folgenden Rollen eingeteilt werden:

• Framework-Entwickler: Entwirft Test-Framework-Komponenten, einschließlich benutzerdefinierter Benutzeroberflächen, Prozessmodelle und Schritttypen.  
• Testentwickler: Erstellt Testsequenzen innerhalb des vom Framework-Entwickler implementierten Frameworks.
• Techniker: Behebt Probleme mit Tests, die in einer Produktionsumgebung ausgeführt werden.
• Testbetreiber: Richtet Prüflinge ein und führt die Tests in einer Produktionsumgebung aus.

Bei der Planung und Gestaltung geeigneter Benutzeroberflächen für Benutzer von Testsystemen übernehmen Sie die Rolle des Framework-Entwicklers.  Mit den TestStand-Benutzeroberflächenelementen können Sie Ihre Benutzeroberfläche vollständig an die Anforderungen Ihrer Benutzer anpassen. Beispielsweise muss ein Testbetreiber möglicherweise nur in der Lage sein, einen Test zu starten und das Ergebnis anzuzeigen.  Ein Testentwickler benötigt jedoch vollen Zugriff auf das Erstellen und Bearbeiten von Sequenzdateien.

Sie können Testentwicklern eine Benutzeroberfläche mit vollem Funktionsumfang zur Verfügung stellen, mit der Sequenzdateien erstellt und bearbeitet werden können, wie das mit TestStand bereitgestellte Full-Featured-Benutzeroberflächenbeispiel oder der Sequence Editor.  Für Testbetreiber können Sie eine einfache Benutzeroberfläche entwerfen, die nur eine Schaltfläche zum Starten des Tests und eine Anzeige mit dem Testergebnis enthält, damit Bediener den Test erfolgreich ausführen können.  Das Bereitstellen von komplexeren Benutzeroberflächen für Bediener kann problematisch sein, da sie zusätzliche Bedienerschulungen erfordern und aufgrund der verfügbaren Funktionen fehleranfällig sind.

Wenn Sie die Benutzeroberfläche mit den TestStand-UI-Elementen entwickeln, können Sie nahtlos von der vollen (full-featured) Benutzeroberfläche zur einfachen Benutzeroberfläche migrieren. Beide Benutzeroberflächen basieren auf der Engine, den Sequenzen, Prozessmodellen und anderen Komponenten von TestStand, die von den Benutzeroberflächen gemeinsam genutzt werden.

Benutzeroberflächen mit vollem Funktionsumfang wie der Sequence Editor und einfache Bedienoberflächen können nahtlos mit demselben Testcode interagieren

Neben der Erstellung separater Benutzeroberflächen können Sie auch mit der TestStand-Benutzerverwaltung anpassen, welche Funktionen in einer einzelnen Benutzeroberflächenanwendung verfügbar gemacht werden.  Dieser Ansatz eignet sich besser in Fällen, in denen unterschiedliche Rollen mit denselben Testausführungen arbeiten.  Beispielsweise benötigen Techniker, die für die Fehlerbehebung bei Testfehlern verantwortlich sind, Zugriff auf Diagnosedaten, wie eine Ansicht des Ausführungs- und/oder des Testprotokolls, das normalerweise nicht für Bediener verfügbar ist.  Eine separate UI-Anwendung für Techniker wäre problematisch, da sie keinen Zugriff auf die aktuellen Ausführungsinformationen aus der separaten Anwendung hätten.  Um das zu beheben, können Sie eine einzelne Benutzeroberfläche erstellen, die zusätzliche Ansichten für fortgeschrittene Benutzer freischaltet.  Beispielsweise kann die TestStand-Benutzeroberfläche mit vollem Funktionsumfang mithilfe von Strg + Umschalt + Alt + Einfügen in den Editormodus umgestellt werden. Dann können Benutzer Änderungen an Sequenzen vornehmen.

Das UI-Beispiel mit vollem Funktionsumfang kann im Bedienmodus oder Editormodus ausgeführt werden

Wenn Sie Benutzer für den TestStand-Benutzermanager definieren, aktivieren oder deaktivieren die TestStand-Benutzeroberflächenelemente automatisch ihren Status basierend auf den Berechtigungen des aktuellen Benutzers. Sie können auch mit der TestStand-API-Methode „Engine.CurrentUserHasPrivilege“ benutzerdefiniertes Verhalten basierend auf Benutzerrechten definieren, z. B. das Ausblenden oder Anzeigen bestimmter Teile der Benutzeroberfläche. Im Hilfethema Managing Users (Verwalten von Benutzern) finden Sie weitere Informationen zum Definieren von Benutzern und Berechtigungen.

Bei der Entwicklung einer TestStand-Benutzeroberfläche müssen Sie deutlich abgrenzen, was in der Benutzeroberfläche und was in anderen Komponenten des Testsystems implementiert wird.  In diesem Abschnitt werden die allgemeinen Testsystemfunktionen beschrieben und erläutert, wo diese in der TestStand-Architektur implementiert werden sollten.

Implementieren des Initialisierungscodes in Front-End-Callbacks

In vielen Fällen erfordert ein Testsystem, dass Aktionen vor der Testausführung durchgeführt werden. Beispielsweise müssen Sie möglicherweise die Testhardware initialisieren und überprüfen, ob sie kalibriert ist, oder die Benutzerrechte zum Initialisieren der Benutzeroberfläche prüfen.

Um diese Funktionen auszuführen, können Sie die LoginLogout-Sequenz in der Sequenzdatei für Front-End-Callbacks verwenden.  Diese Sequenz wird standardmäßig vom Manager-Element der TestStand UI-Anwendung ausgeführt, wenn TestStand gestartet wird. Sie zeigt dem Benutzer standardmäßig den Anmeldedialog an.  Das Hinzufügen von Funktionen zu dieser Sequenz bietet die folgenden Vorteile:

• Alle TestStand-Benutzeroberflächen und der Sequence Editor rufen dieselbe LoginLogout-Sequenz auf. So können Sie Funktionen definieren, auf die Sie von jeder Benutzeroberfläche aus zugreifen können, und doppelten Code vermeiden.
• Sie können das Verhalten des zusätzlichen Codes ändern, ohne Änderungen an den Benutzeroberflächen vornehmen zu müssen.

Zusätzlich zur LoginLogout-Sequenz können Sie weitere Sequenzen in den Front-End-Callbacks definieren, um Funktionen zu implementieren, die zu einem anderen Zeitpunkt aufgerufen werden.  Für diese zusätzlichen Sequenzen müssen Sie der Benutzeroberfläche Code hinzufügen, um die Sequenz zum gewünschten Zeitpunkt mit der Engine.CallFrontEndCallbackEx()-Methode aufzurufen.  Dieser Ansatz bietet sich an, da Sie keine Referenz zu einer Sequenzdatei verwalten müssen, weil der Front-End-Callback automatisch von TestStand geladen und entladen wird.  

Verwenden des Menüs „Tools“ (Werkzeuge) für den Zugriff auf zusätzliche Anwendungen

Ein Testsystem nutzt häufig separate Tools oder Anwendungen zusätzlich zum Test.  Beispielsweise können Sie ein Datenbankkonfigurationsprogramm oder eine Analyseanwendung starten.  Anstatt diese Funktionen als Module einer Benutzeroberflächenanwendung zu erstellen, können Sie Ihr System modularisieren. Dazu fügen Sie eigenständige Tools ein und ermöglichen den Zugriff auf diese über benutzerdefinierte Elemente im Tools-Menü.  Sie können das Tools-Menü im Sequence Editor über das Menü „Tools“ (Werkzeuge) » „Customize“ (Anpassen) anpassen. Im Dialogfeld „Customize“ (Anpassen) können Sie neue Tools-Menüelemente hinzufügen und deren Verhalten konfigurieren.

Erstellen Sie benutzerdefinierte Tools, um jeder Benutzeroberfläche, die das Tools-Menü implementiert, zusätzliche Funktionen bereitzustellen

Von Ihnen vorgenommene Änderungen werden in einer separaten Konfigurationsdatei gespeichert, sodass auf allen Benutzeroberflächen dieselben benutzerdefinierten Einträge angezeigt werden, die Sie erstellen.  Weitere Informationen finden Sie im Hilfethema zum Dialogfeld „Customize Tools Menu“ (Werkzeugmenü anpassen).

Verwenden von Prozessmodellen zum Definieren von Sequenzeintrittspunkten

Eine Benutzeroberfläche muss Benutzern die Möglichkeit bieten, Sequenzausführungen zu starten. Die Benutzeroberfläche darf jedoch nicht direkt mit einer Sequenzdatei gekoppelt sein.  Damit Benutzer Tests starten können, können Sie eine Schaltfläche erstellen, die einen Ausführungseintrittspunkt der aktuell geladenen Sequenz aufruft, einschließlich der direkten Ausführung der Sequenz oder der Verwendung eines Eintrittspunkts für ein Prozessmodell, z. B. Single Pass und Test UUTs.  Die Benutzeroberfläche darf keine Funktionen enthalten, die vor oder nach einer Sequenzausführung ausgeführt werden. Implementieren Sie diese Funktionalität stattdessen über das Prozessmodell.

Die Prozessmodelle können ebenfalls Konfigurationseintrittspunkte definieren, mit denen Benutzer Einstellungen für Prozessmodelle konfigurieren können. Stellen Sie sicher, dass alle Modelleinstellungen über diese Eintrittspunkte und nicht direkt über die Benutzeroberfläche konfiguriert werden. Durch das Integrieren von Funktionen in das Prozessmodell werden die Funktionen in jeder TestStand-Benutzeroberflächenanwendung und im Sequence Editor verfügbar gemacht.

Weitere Informationen zur Verwendung von Prozessmodellen finden Sie im Dokument Best Practices for TestStand Process Model Customization (Empfohlene Methoden für die Anpassung von TestStand-Prozessmodellen).

Während es wichtig ist, dass die Benutzeroberfläche von anderen Komponenten des Testsystems wie Testsequenzdateien und Prozessmodellen entkoppelt ist, muss die Benutzeroberfläche effektiv mit diesen Komponenten kommunizieren können.  Dieser Abschnitt enthält Ansätze für die Kommunikation zwischen diesen Komponenten unter Beibehaltung dieser Modularität.

Kommunikation zwischen der Sequenz und der Benutzeroberfläche

Während der Ausführung eines Tests muss das Testsystem dem Bediener eine Rückmeldung geben, die den aktuellen Status der Ausführung angibt, z. B. welcher Test ausgeführt wird oder die aktuellen Testergebnisse. Im Allgemeinen können Sie TestStand-UI-Elemente verwenden, um diese Informationen anzuzeigen, z. B. eine Ausführungsansicht und eine Protokollansicht. Wenn Sie diese Elemente mit einem Manager-Element verbinden, werden sie immer aktualisiert, um den aktuellen Ausführungsstatus anzuzeigen, der von der Engine verwaltet wird.

In einigen Fällen möchten Sie möglicherweise spezifischere Informationen zum Test anzeigen.  Die ausführende Sequenz oder das Codemodul muss diese Informationen zur Anzeige an die Benutzeroberfläche weitergeben oder die Benutzeroberfläche anweisen, eine Aktion auszuführen. Um diese Informationen zu kommunizieren, ohne eine Kopplung einzuführen, können Sie UI-Nachrichten für die Implementierung der Kommunikation verwenden. Wenn Sie alternativ dazu eine Sequenzdateieigenschaft oder eine UI-Variable als Kommunikationsmittel verwenden, führt das zu unerwünschten Abhängigkeiten zwischen Sequenzdateien und der Benutzeroberfläche. Wenn Sie beispielsweise eine globale Dateivariable aus der Sequenz aktualisieren und dann ihren Status in der Benutzeroberfläche prüfen, wird eine Kopplung zwischen der globalen Variablen und der Benutzeroberfläche eingeführt.   UI-Nachrichten werden aus zwei Gründen bevorzugt:

1. Unabhängigkeit von Benutzeroberfläche und Sequenzdateien – Eine Benutzeroberfläche sollte immer mit jeder Sequenzdatei funktionieren und umgekehrt.  Bei Verwendung von UI-Nachrichten ist es nicht erforderlich, dass bestimmte Eigenschaften in Sequenzdateien vorhanden sind, wenn diese mit der Benutzeroberfläche verwendet werden.  Mit UI-Nachrichten:
   • Die Benutzeroberfläche kann Sequenzen ausführen, die bestimmte Nachrichten nicht implementieren (der Verarbeitungscode in der Benutzeroberfläche wird einfach nie ausgeführt).
   • Sequenzen, die benutzerdefinierte Nachrichten veröffentlichen, können in einer Benutzeroberfläche ausgeführt werden, die nicht dafür ausgelegt ist (die UI-Nachricht wird von der Benutzeroberfläche einfach ignoriert).
2. Verwaltbarkeit – UI-Nachrichten vermeiden die Abhängigkeit von Sequenzdateieigenschaften oder UI-Variablen. Das bedeutet weniger Wartungsaufwand für Entwickler von Sequenzdateien und Benutzeroberflächen.

Weitere Informationen zu den Vorteilen von UI-Nachrichten finden Sie unter „Using TestStand User Interface Messages (UI Messages)“ (Verwenden von TestStand-UI-Nachrichten).

Typen von UI-Nachrichten

UI-Nachrichten enthalten eine Nachrichten-ID, die den Zweck der Nachricht angibt.  TestStand definiert mehrere UI-Nachrichten-IDs. Diese definieren Nachrichten, die entweder automatisch von der Engine gesendet oder von den Bedienelementen der TestStand-Benutzeroberfläche automatisch verarbeitet werden.  Beispielsweise wird die Nachrichten-ID UIMsg_EndExecution (Wert 4) von der Engine nach Beendigung einer Ausführung gesendet.  Die Manager-Elemente stellen viele dieser UI-Nachrichten als einzelne Ereignisse bereit. In diesem Fall können Sie einen Handler für das ApplicationManager EndExecution-Ereignis definieren, anstatt einen UI-Nachrichten-Ereignisbehandler direkt zu verwenden.

Andere UI-Nachrichten werden von den Standardprozessmodellen gesendet, z. B. UIMsg_ModelState_Identified (Wert: 32). Diese werden nach Identifizierung der Seriennummer des Prüflings von den Prozessmodellen veröffentlicht.  Darüber hinaus können Sie vordefinierte oder benutzerdefinierte UIMessages aus Ihren Codemodulen, Testsequenzen oder dem Prozessmodell mithilfe der TestStand-API-Methode Thread.PostUIMessageEx veröffentlichen.

Eine Liste der UI-Nachrichten-IDs oder Ereigniscodes finden Sie im Hilfethema UIMessageCodes.

Sie können Ihre eigenen UIMessages für benutzerdefinierte Vorgänge definieren, wie das Aktualisieren von Daten in einem Diagramm und einem Histogramm. Wenn Sie benutzerdefinierte UIMessages definieren, geben Sie eindeutige Ereigniscodes ab dem UIMsg_UserMessageBase-Ereigniscode an. Wenn Sie eine benutzerdefinierte UIMessage veröffentlichen, übergeben Sie den definierten Ereigniscode und die anzuzeigenden Daten. UI-Nachrichten enthalten Datenfelder für numerische, String- oder ActiveX-Daten, die Sie beim Aufrufen der postUIMessageEx-Methode angeben. Wenn Sie einen Handler definieren, der auf die UI-Nachricht in der Benutzeroberfläche reagiert, werden diese Daten als Parameter im Ereignis-Callback angezeigt.

Um zu definieren, wie eine Benutzeroberfläche UI-Nachrichten verarbeitet, konfigurieren Sie die Bedienoberfläche so, dass benutzerdefinierter Code ausgeführt wird, wenn eine UI-Nachricht verarbeitet wird. Fügen Sie dazu einen Ereignis-Callback für eines von zwei Application Manager-Ereignissen hinzu:

• UImessage-Ereignis: Dieses Ereignis wird immer dann ausgelöst, wenn eine UI-Nachricht vom Application Manager verarbeitet wird.  Der angegebene Ereignis-Callback wird vor allen standardmäßigen UI-Nachrichtenverarbeitungsvorgängen ausgeführt.  Das Argument zum Abbrechen des Ausgabeereignisses kann im Callback auf „True“ gesetzt werden, um die Standardereignisvorgänge zu überschreiben.
• UserMessage-Ereignis: Dieses Ereignis wird nur bei benutzerdefinierten UI-Nachrichten ausgelöst (Nachrichten mit einer Nachrichten-ID von 10.000 oder höher).  

Informationen zum Definieren von Ereignisbehandlern für eine Benutzeroberfläche finden Sie im Thema zum Behandeln von Ereignissen in der TestStand-Hilfe.

Kommunikation von der Benutzeroberfläche zum ausgeführten Test

In einigen Fällen möchten Sie möglicherweise Informationen von der Benutzeroberfläche an die Testsequenz übermitteln.  Die Kommunikation zwischen einer Sequenz und einer Benutzeroberfläche sollte jedoch immer von der Sequenz eingeleitet werden, um sicherzustellen, dass sich die Sequenz in einem Zustand befindet, in dem ihre Daten geändert werden können.  Um das zu erreichen, kann die Sequenz eine UI-Nachricht mit einem benutzerdefinierten Code veröffentlichen, um anzugeben, dass sie für die Kommunikation bereit ist. Wenn Sie die UIMessage veröffentlichen, setzen Sie den synchronous-Parameter auf „True“, damit die Ausführung wartet, bis die Benutzeroberfläche die Nachricht verarbeitet hat. Wenn die Benutzeroberfläche die UIMessage verarbeitet, ruft sie das SequenceContext-Objekt ab und schreibt oder liest bestimmte Variablen, z. B. die lokalen Variablen des Prozessmodells.
In vielen Fällen ist die Benutzeroberfläche nicht der beste Ort für die Angabe von testbezogenen Daten.  Wenn sich die Daten beispielsweise auf Tasks in den Prozessmodellen beziehen, sollte besser ein Konfigurationseintrittspunkt geändert oder erstellt werden, auf den Sie über das Standardmenü zugreifen können.

Ein Beispiel für das Veröffentlichen und Verarbeiten von UI-Nachrichten, einschließlich der Verwendung von UI-Nachrichten zum Erfassen von Daten über die Benutzeroberfläche, finden Sie im bereitgestellten Beispiel Handling UI Messages (UI-Nachrichten verarbeiten).

Klicken Sie hier, um weitere Dokumente der TestStand Advanced Architecture-Serie mit interessanten Themen für fortgeschrittene NI-TestStand-Entwickler anzuzeigen.