29 A.06.01.e

29.1 Kompatibilität

Das Binärformat hat sich geändert. Binärdateien müssen neu generiert werden.

29.2 Windows

12701: Beim Schließen eines Fensters mit überschriebener :set-Methode kommt es nicht mehr zu einem Assfail. Das Problem trat auf, wenn die :set-Methode beim Sichtbarmachen des Fensters aufgerufen wurde, beim Unsichtbarmachen aber nicht (zum Beispiel durch Klick auf das Schließen-Symbol in der Titelleiste).

12668 (keine Änderung): Das Treeview-Control unter Windows stellt maximal 256 Hierarchiestufen dar.

29.3 Qt

12712: Die Option opt_auto_close am Fenster wird nun auch für Qt unterstützt. Beim Schließen des Fensters wird nur das close-Ereignis erzeugt ohne das Fenster unsichtbar zu schalten.

29.4 Kern

12694: Es kommt zu keiner fehlerhaften Parameterprüfung mehr, wenn man Regeln aufruft unter Ausnutzung von Defaultwerten, bei denen der Rückgabewert wiederum Parameter eines erneuten Regelaufrufs ist. Zusätzlich wird nun die Gültigkeitsprüfung des Defaultwertes direkt beim Laden ausgeführt.

12691: Beim Löschen eines Attributs wird nun nicht mehr über allokierte Speicherbereiche hinaus geschrieben und kein ungültiger Heap bzw. ungültige Speicherverwaltung hinterlassen.

12687: Beim Binärschreiben eines Tablefields mit gesetztem .rowheader oder .colheader kommt es nicht mehr zum Überschreiben von .content[I,J]-Strings des Headers mit Strings nach dem Header (.field[I,J]).

12678: Wenn ein Attribut an einer Instanz gelöscht wird, werden bei der Berechnung von .itemorder nun geerbte Attribute berücksichtigt. Auf lokal gesetzte Attribute wird nun geachtet, um das Attribut an der richtigen Stelle der Ordnung wegzunehmen.

12676: Der IDM Builder Prozess bricht nun auch im zweiten Lauf bei Fehlern konsistent ab.

12637: Bei Regeln unterhalb von exportierten Objekten kommt es nicht mehr zu Fehlern bei der statischen Überprüfung des Gültigkeitsbereichs.

29.5 Unterstützung von Microsoft UI Automation

Verfügbarkeit

Nur IDM für Windows

UI Automation (im Folgenden meist mit UIA abgekürzt) ist ein Framework von Microsoft um die Barrierefreiheit (Accessibility) und das automatisierte Testen von Benutzeroberflächen zu ermöglichen.

Der Fokus bei der Erweiterung des IDM liegt dabei auf der Bereitstellung der Infrastruktur für das automatisierte Testen.

Es macht dabei die Oberflächenelemente (UIA Elements) in einer Baumstruktur zugänglich. Wobei ein UIA Element Eigenschaften (Properties) aufweist, abhängig auch von seinem Typ (UIA Control Type). UIA Elemente können außerdem mehrere Steuerungsmuster (UIA Control Patterns) aufweisen, welche zusätzliche Eigenschaften oder Interaktionsmöglichkeiten (UIA Control Pattern Methods) bieten. Ereignisse zeigen dabei an, ob sich an einem UIA Element Änderungen ergeben haben.

Diese Dokumentation dient dazu, die Funktionalität des IDM bezüglich der UI Automation Unterstützung kenntlich zu machen und ist weitestgehend nur für Entwickler von UI Automation Clients interessant. Es stellt keine Programmierdokumentation dar, sondern dokumentiert lediglich die Unterstützung durch den IDM. Für die Nutzung von UI Automation sei auf die Microsoft-Dokumentation verwiesen.

29.5.1 Zuordnung von IDM-Objektklassen zu UIA Control Types

Der IDM hat als ein Designprinzip die Verwendung der vom System bzw. Toolkit bereitgestellten Objektklassen (Controls, Widgets) um die Oberflächenobjekte zu implementieren und damit Bedienung und Aussehen möglichst konform zum System zu halten.

Eine Vielzahl von IDM-Objektklassen werden durch den UI Automation Support for Standard Controls von Microsoft abgedeckt. Der IDM ergänzt wenn möglich und erforderlich noch die notwendigen Eigenschaften.

Im Hinblick auf die UI Automation Unterstützung im IDM lassen sich folgende Kategorien unterschieden:

Die folgende Tabelle soll einen Anhaltspunkt für die Zuordnung der IDM-Objektklassen zu UIA Control Types liefern sowie der bereitgestellten Funktionalität durch die Pattern-Zugehörigkeit:

Änderungen an der UI Automation Unterstützung können durch Microsoft jederzeit erfolgen, sodass bezüglich den Zuordnungen zu UIA-ControlTypes, Patterns, Properties und Events jederzeit Änderungen möglich sind.

29.5.2 Unterstützte UIA Properties und Control Pattern Methoden

Grundsätzlich sind die Properties, Methoden und Funktionalität durch die UI Automation Specification vorgegeben. Dieses Kapitel hat also eher einen informativen Charakter um den Zusammenhang mit dem IDM herzustellen.

29.5.2.1 Value Pattern

29.5.2.2 RangeValue Pattern

29.5.2.3 Scroll Pattern

29.5.2.4 ScrollItem Pattern

29.5.2.5 Transform Pattern

29.5.2.6 Grid Pattern

29.5.2.7 GridItem Pattern

29.5.2.8 Selection Pattern

29.5.2.9 SelectionItem Pattern

29.5.2.10 Toggle Pattern

29.5.2.11 ExpandCollapse Pattern

29.5.2.12 Window Pattern

29.5.2.13 Dock Pattern

29.5.2.14 Table Pattern

29.5.2.15 TableItem Pattern

29.5.3 UIA Objektidentifikation

Die von UI Automation definierten Schlüssel-Properties für die Identifikation von UIA Elementen sind AutomationId, Name, ControlType und RuntimeId.

Um eine möglichst konsistente und sprachunabhängige Identifikation zu ermöglichen, wird deshalb bei den meisten IDM-Objekten der IDM Objekt-Label als AutomationId vergeben. Bei Mehrdeutigkeiten erfolgen bei geerbten Bezeichnern noch die IDM-typische Indizierung :[<Nr>] nach dem Label für Nr >= 2. Über das .acc_label-Attribut kann die AutomationId überschrieben werden. Dann hat allerdings der Anwendungsprogrammierer für die Eindeutigkeit zu sorgen.

Oft wird auch die Name-Property herangezogen, welche typischerweise den sichtbaren statischen Text-String (also nicht dem dynamischen Inhalt) widerspiegelt. Auch dies ist vom Anwendungsprogrammierer überschreibbar durch das .acc_text-Attribut.

In einem UI Automation Element Tree sind durch diese Properties damit Objekte meist eindeutig identifizierbar.

Die RuntimeId basiert im allgemeinen auf dem Window-Handle und kann sich somit auch bei Attributänderungen ändern. Sie eignet sich somit weniger für eine stabile Objektidentifikation.

29.5.4 Besonderheiten

29.5.4.1 Edittext

Für die Änderung des Textes ist die Methode SetValue() des Value Pattern zu benutzen. Dies führt zu einem charinput-Ereignis im IDM. Das modified-Ereignis um eine Änderung zu signalisieren wird allerdings erst versendet, wenn der Edittext den Fokus verliert. Konsistenter mit einer normalen Bedienung ist die Simulation von Tastatureingaben. Generell sollte der Fokus über die SetFocus()-Methode von UIA auf das Eingabefeld gelenkt werden.

29.5.4.2 Poptext

Neben der üblichen Methodik, die Selektion über die Select()-Methode des SelectionItem Patterns zu verändern, kann ebenso die Methode SetValue() des Value Patterns benutzt werden. Handelt es sich dabei um einen editierbaren Poptext, so wird, falls der Wert in der Poptext-Liste aufgeführt ist, eine Selektion vorgenommen und die entsprechenden select- und activate-Ereignisse erzeugt. Andernfalls wird der Inhalt des Editierbereichs umgesetzt und die Ereignisse charinput und modified ausgelöst.

29.5.4.3 Formatierte Eingabe

Wird bei einem Eingabefeld ein Format verwendet, so liefern Text und Value immer den Darstellungstext inklusive Formatierungszeichen. Ein Zugriff auf den Inhalt von Passwortfeldern bei einem verdeckten Format ist somit nicht möglich. Eine vollständige Änderung sollte ebenso über die SetValue()-Methode erfolgen und darf keine Formatierungszeichen beinhalten. Ansonsten sollten Testwerkzeuge die Simulation der Tastatureingaben durchführen.

29.5.4.4 Client-Bereich

IDM-Objektklassen können aus mehreren UIA Elementen bestehen. Gruppierungsobjekte haben typischerweise ein übergeordnetes Element und einen Client-Bereich, welcher den Suffix #client als AutomationId bekommt.

29.5.4.5 Virtuelle Bereiche

Gruppierungsobjekte erhalten einen virtuellem Bereich und optionale Scrollbars durch Setzen der Attribute .vwidth und .vheight. Das Client UIA Element erhält dann zusätzlich das Control Pattern Scroll und ScrollItem an den Kind-Objekten um so die Änderung des sichtbaren Bereichs und das Scrolling eines Kindes in den sichtbaren Bereich zu ermöglichen.

Durch die UIA-Methoden Scroll() bzw. ScrollIntoView() ist die Kontrolle über den angezeigten Ausschnitt möglich. Eine Scrolling-Kontrolle über die innen liegenden ScrollBar UIA Elemente ist nicht möglich.

29.5.4.6 Splitbox

Die einzelnen sichtbaren Bereiche sind als UIA-Kind-Elemente vom Typ Pane mit Namenssuffix #client[1] … #client[n] erreichbar und können durch die Resize() Control Pattern Methode in ihrer Größe geändert werden.

29.5.4.7 Menüs

Menüs in der Menüleiste wie auch Popup-Menüs sind nicht vom IDM überdefiniert sondern durch die Standard-Implementierung von Windows abgedeckt. Typischerweise sind die UIA Elemente der Menüs, Untermenüs und Menüeinträge erst beim Öffnen zugänglich. Kontextmenüs sind dabei unterhalb des Desktop UIA Elements eingeordnet. Die Menüs von Menüleisten liegen nach dem Öffnen direkt unter dem UIA Window Element.

29.5.4.8 Messagebox und Filereq

Beim querybox()-Aufruf werden diese durch Standard-Controls aufgebaut und sind typischerweise als UIA Control Type Dialog oder Window mit dem gesetzten Fenstertitel zu finden.

29.5.4.9 Image-Objekt

Um eine Erkennung des dargestellten Bildes zu erlauben, wird das Image-Objekt in UI Automation durch das UI Element Button mit den Kind-Elementen Image und Text repräsentiert. Das Image-Element erhält, wenn vorhanden, den Alternativtext der verwendeten Tile-Ressource in der UIA Name Property.

29.5.4.10 Toolbar-Objekt

Eine eingedockte Toolbar besitzt kein Transform Pattern, kann also nicht in Größe und Position variiert werden.

29.5.4.11 Treeview-Objekt

Eine erneute Selektion des gleichen Elements, über die Select()-Methode des SelectionItem Pattern, erzeugt kein erneutes select-Ereignis.

29.5.4.12 Benutzerinteraktion vs. Automatisierung

Die Funktionalität zur Automatisierung einer Benutzeroberfläche, die durch UI Automation möglich ist, deckt nicht alle Möglichkeiten ab, die einem Benutzer durch die Bedienung mit Maus und Tastatur gegeben sind.

• Tastatureingaben wie auch der Aufruf von Acceleratoren oder Mnemonics sind nicht direkt vorgesehen. Dies bedeutet aber auch, dass Aktionen bzw. Ereignisregeln, die z.B. auf Enter (Return), Esc, Cursortasten, usw. oder einer Funktionstaste basieren, nicht direkt durch UIA-Methoden angestoßen werden können. Es empfiehlt sich unter Umständen also die Simulation von speziellen Tasten um z.B. das Auslösen von deselect_enter-Ereignisregeln zu ermöglichen.
• Die Interaktionsmuster der Maus (Bewegen, Drücken und Loslassen einer Maustaste) sind ebenso kein Bestandteil der UIA-Methoden. Eine Interaktion in der Form Poptext anklicken – mit gedrückter Maustaste nach unten fahren – über dem 3. Eintrag loslassen ist z.B. schlecht oder gar nicht simulierbar. Ein Mausklick entspricht meist der UIA-Methode Invoke() oder Select(), unter Umständen aber auch einem Expand() oder Collapse() und vieles mehr. Die Benutzerinteraktion ist also vom Control Type abhängig.

Grundsätzlich ist zu sagen, dass sich Benutzerinteraktion und Automatisierung bei den möglichen Aktionen, der Atomarität wie auch den Zustandsabhängigkeiten unterscheiden.

29.5.5 Hinweise zu HP UFT 12.52

Das Testwerkzeug HP Unified Functional Testing (UFT) bietet ab Version 12.52 eine Unterstützung für das Testen von UI Automation. Dabei weist UFT aber keine vollständige Unterstützung für alle UIA Control Types auf, sondern beschränkt sich auf die wichtigsten Control Types und Control Patterns. Dieses Kapitel ist also lediglich informativer Art und sollte keinen Blick in die UFT-Dokumentation ersetzen.

Die Unterstützung von UIA (UI Automation) durch UFT lässt sich wie folgt beschreiben:

• Das UI Automation Add-In muss aktiv sein.
• Zur Identifikation über den Objekt-Spion muss der UI Automation Modus aktiv sein.
• Die Objektidentifikation erfolgt über die UIA Properties Name und AutomationId.

• Es werden folgende UIA Control Types erkannt und in ein entsprechendes UFT-Objektmodell überführt:

  UIA Control Type	UFT-Objektmodell
  Button	UIAButton
  Calendar	UIACalendar
  CheckBox	UIACheckBox
  ComboBox	UIAComboBox
  Edit	UIAEdit
  HyperLink	UIAHyperLink
  List	UIAList
  RadioButton	UIARadioButton
  Slider	UIASlider
  Tab	UIATab
  DataGrid	UIATable
  SplitButton	UIASplitButton
  Window	UIAWindow
  Table	UIATable
  ... andere ...	UIAObject

• Folgende UIA Control Patterns werden durch UFT über spezielle Methoden an den UIA-Objekten unterstützt:

  UIA Control Pattern	UFT-Methoden
  ExpandCollapse	.Expand .Collapse
  Grid	.GetItem
  Invoke	.Click
  RangeValue	.Decrement .Increment .SetValue
  Scroll	.Scroll .ScrollDown .ScrollUp .ScrollLeft .ScrollRight .SetScrollPercent
  ScrollItem	.ScrollIntoView
  Selection	.Select .AddToSelection .RemoveFromSelection .GetSelection
  SelectionItem	.Select .AddToSelection .RemoveFromSelection
  Table	.GetRowHeaders .GetColumnHeaders
  TableItem	.GetRowHeaderItems .GetColumnHeaderItems
  Transform	.Move .Resize .Rotate
  Toggle	.Set
  Value	.SetValue
  Window	.Maximize .Minimize .Restore .Close

Dies bedeutet, dass nicht alle IDM-Objektklassen unterscheidbar als Testobjekte mit eigener UIA-Klasse von UFT erkannt werden. Dazu gehören die IDM-Objektklassen:

• toolbar
• statusbar
• scrollbar
• splitbox
• menubox, menuitem, menusep
• spinbox
• progressbar
• image
• rectangle
• control
• layoutbox, groupbox, splitbox
• edittext (RTF)

Allerdings sollten diese von UFT als allgemeines UIAObject erkannt werden und durch die unterstützten Pattern-Methoden hinreichend test- und manipulierbar sein.

Es sei angemerkt, dass Microsoft mit UI Automation zwar die Bereiche Accessiblity und Test Automation abdeckt, allerdings keine vollständige und korrekte Erfassung von Benutzerinteraktion ermöglicht. Insofern ist ein Recording der Benutzerinteraktion durch UFT im UI Automation Modus oft unvollständig und unter Umständen auch fehlerbehaftet.

Dies zeigt sich z.B. beim Recording einer Menüinteraktion auf einem Untermenü. UFT generiert das folgende, nicht funktionsfähige Skript, welche keinen Click auf das Menü enthält:

UIAWindow("Hauptfenster").UIAMenu("Anwendungsmenü").UIAObject("Datei").Expand
UIAWindow("Hauptfenster").UIAMenu("Datei").UIAObject("Untermenü").Expand

Ein funktionierendes Skript würde hingegen wie folgt aussehen:

UIAWindow("Hauptfenster").UIAMenu("Anwendungsmenü").UIAObject("Datei").Click
UIAWindow("Hauptfenster").UIAMenu("Datei").UIAObject("Untermenü").Click
UIAWindow("Hauptfenster").UIAMenu("Datei").Select "Untermenü;Menü A"

Beim Recording im Windows-Modus erhält man etwa folgendes funktionstüchtiges Skript:

Window("Hauptfenster").WinMenu("Datei").Select "Datei;Untermenü;Menü A"

29.5.6 Erweiterung zur C-Schnittstelle

Die Funktionen DM_Control() und DM_ControlEx() wurden um eine zusätzliche Aktion ergänzt. Standardmäßig ist die Unterstützung von UI Automation aktiv. Mit dieser Aktion kann die spezielle Unterstützung des IDM für seine besonderen Objekte abgeschaltet werden. Weiterhin aktiv bleibt aber die UI Automation Unterstützung von Microsoft für die Standard Controls.

Die Umschaltung muss dabei vor dem Aufruf von DM_Initialize() und nach dem Bootstrapping erfolgen. Ein erfolgreiche Umsetzung wir mit der Rückgabe von DM_TRUE angezeigt.

29.5.7 Attribut .acc_text

Mit diesem Attribut kann der Automation-Name überschieben werden, der für ein Oberflächenobjekt über die Microsoft UIA-Schnittstelle vom IDM erfragt wird. Bei einem Wert von null wird der Name normalerweise vom Windows Control bzw. durch die UIA-Unterstützung im IDM sinnvoll vorgegeben.

Unterstützung des Attributs durch Objekte

Anmerkung

Dieses Attribut ist nur für die automatisierte Fremdsteuerung mit aktiver Microsoft UIA-Unterstützung relevant. Unter Qt und Motif hat dieses Attribut keine Funktion.

29.5.8 Attribut .acc_label

Mit diesem Attribut kann der Automation-Identifikator überschieben werden, der für ein Oberflächenobjekt über die Microsoft UIA-Schnittstelle vom IDM erfragt wird. Bei einem leeren String wird der Automation-Identifikator normalerweise vom Windows Control bzw. durch die UIA-Unterstützung im IDM sinnvoll vorgegeben.

Unterstützung des Attributs durch Objekte

Anmerkung

Dieses Attribut ist nur für die automatisierte Fremdsteuerung mit aktiver Microsoft UIA-Unterstützung relevant. Unter Qt und Motif hat dieses Attribut keine Funktion.

Bei einer Überschreibung sollten die Regeln beachtet werden, welche in der Microsoft UI Automation Dokumentation für die AutomationId vorgegeben sind.

29.5.9 Erweiterung der Tile-Ressource

Für den Zugang zu IDM-Oberflächenobjekten über die UI-Automation Schnittstelle unter Microsoft Windows wurde die Tile-Ressource ergänzt. Image-Objekte, welche eine Tile-Ressource als Bild (Muster) nutzen, erhalten einen Alternativtext um die Automatisierung und Zugänglichkeit (Accessibility) zu erleichtern.

Dieser Alternativtext in kann dabei wie folgt angegeben werden:

{ export | reexport } tile  <Bezeichner>  <x>, <y>,
      <Tilestring1>
  [ , <Tilestring> ]
{ scale } { text(<Alternativtext>) };

{ export | reexport } tile  <Bezeichner>  <Dateiname>
  { scale } { text(<Alternativtext>) };

<Alternativtext> := ( <String> | <Text-Objektpfad> )

Beispiele

text TxPause "Pause"
{
  2: "Break";
}
tile TiCoffeeBreak "kaffeetasse.gif" text("Pause");
tile TiCoffeeBreak "kaffeetasse.gif" text(TxPause);

29.5.10 Erweiterung des Tracing

Um eine Trace-Ausgabe der UIA-Schnittstelle des IDM für Windows zu aktivieren, muss das UI Automation Tracing explizit (zum Beispiel in der on dialog start Regel) eingeschaltet werden:

setup.tracing["AU"] ::= true;  /* "AU" = Automation */