Für die Automatisierung von Test steuern wir eine große und alte Anwendung von aussen. Dabei ist es gut wenn man z.B. Controls nur dann beschreibt, wenn die Anwendung auch bereit ist. Ein häufiges Szenario ist, dass ein Knopf gedrückt wird, wobei dann ein (anderes) Menüband erscheint welches Controls enthält. Nur wann ist das Menüband bereit? So genau kann man das nicht sagen weil auch noch Timer im Hintergrund laufen.

Im Moment geben wir ein Control zur Prüfung mit. Das Menüband ist dann bereit, wenn
a) das Tab, auf dem das Control sichtbar ist
b) Wenn das UI nicht gelocked ist
c) das Control selber Showing ist
Als Ideen gab es mal noch:
d) wenn die CPU-Auslastung runter geht: hat sich nicht so bewährt
e) wenn die Windows-Botschaftswarteschlange leer ist (wm_Paint ist die letzte): ein Teilversuch mache ich gerade

Irgendwelche Ideen dazu? (Auch von Kathinka )

Aber das ist doch nur geraten. Warum gibt die Anwendung kein Signal wenn sie "bereit" ist? Oder lässt sich fragen?

Das ist eindeutig und einfach umzusetzen. Möglichkeiten gibt es genug. Umgebungsvariablen setzen, antworten auf eine bestimmte Windows-Botschaft, ...

Hallo,
Danke für die Antwort. Die Anwendung lässt sich schon fragen, das machen wir auch (über TCP/IP). Das habe ich leider nicht eindeutig geschrieben.

Die Frage ist eher woher soll die Anwendung selber wissen wenn sie bereit ist. Wenn zum Beispiel die Controls alle Visible sind ist die Anwendung nach unserer Erfahrung noch lange bereit. Wenn man dann z.B. in ein Edit-Feld schreibt verhält sich die Anwendung teilweise komisch. Eine bestimmte Zeit zu warten ist auch keine gute Lösung weil die (virtuellen) Maschinen unterschiedlich schnell sind. In den einem Fall ist es Zeitverschwendung, im anderen ist es zu knapp und die Tests schlagen fehl. (Und mit "lass den Test doch auf der VM7 lauen, da gibts am wenigsten Probleme" bin ich auch nicht so recht zufrieden.)

Ich bin gerade dabei zu untersuchen ob ein Abwarten auf WM_PAINT in einem Control die Sache verbessert. (Tests laufen gerade)

Hallo, eine Möglichkeit wäre möglicherweise Application.OnIdle zu nutzen.
Ich selber nutze das beim Programmstart um einen Anmeldedialog aufzurufen.

Zitat von Der schöne Günther:

Aber das ist doch nur geraten. Warum gibt die Anwendung kein Signal wenn sie "bereit" ist? Oder lässt sich fragen?

Das ist eindeutig und einfach umzusetzen. Möglichkeiten gibt es genug. Umgebungsvariablen setzen, antworten auf eine bestimmte Windows-Botschaft, ...

Würde ich so unterschreiben. Die Anwendung wartet auf Eingaben, ist beschäftigt oder ist beschäfigt und kann gleichzeitig Eingaben entgegennehmen. Wenn man da raten muß ist das suboptimal egal ob eine neue oder alte Anwendung. (Ich hab auch noch solche Leichen im Keller, ist trotzdem S********)

Gruß
K-H

Ja schon. Nur hilft mir das nicht weiter. "Das ist eindeutig und einfach umzusetzen." - aber wie? Und auch für die Leichen im Keller sollte das funktionieren.

@BerndS: Ah ja Application.OnIdle, hatte ich gar nicht daran gedacht, baue ich noch ein.

Das kommt darauf an was in der anwendung geschieht. Wenn z.b. ein thread sich nicht zurück meldet (EndMessage) dann hilft nur noch raten. Oder das beliebte Dateilesen,daß ist fertig wenn es fertig ist. Und wenn zwischendurch jemand eine Eingabe tätigen will wird das eben abgewiesen. (Button.Enabled:=false)
Dieses einfache Strickmuster sollte immer im Hinterkopf behalten und immer beherzigen egal wie weit man es mit der Komplexität treibt.

Gruß
K-H

Warum nicht einfach mit globalen Sperr-Flags arbeiten?
Wenn einzelne Aufgaben abgearbeitet werden, werden entsprechende Flags gesetzt.
Nur wenn keine Flags gesetzt sind, ist das Programm bereit.

Ob da eine Anfrage von außen kommt, spielt ja für die Bereitschaftsentscheidung keine Rolle. Die könnte auch in einem Timer o.ä. für programminterne Aufgaben geprüft werden...

Danke für Eure Beiträge.

Das mit den Flags ist leider nicht so "einfach". Man müsste ja wissen wann die jeweils zu setzen sind. Wir haben zig verschiedene Menübänder.
Ein typischer Ablauf geht stark vereinfacht so:
- Anwender klickt auf Knopf -> TAction
- TAction aktiviert eine Command-Klasse
- diese meint eine UI haben zu müssen, kennt jedoch keine UI direkt
- eine registrierte Hilfsklasse wird aktiv
- die Statemachine für die UI schaltet um, bei der Transition wird
- die UI erzeugt, das Viewmodel (sofern vorhanden) erzeugt und dieses samt der Command-Klasse dem UI reingeschoben
- das Viewmodel nimmt seine Arbeit auf, holt Daten von der Command-Klasse und füllt sich selber ab
- das Viewmodel synchronisiert über das Binding das UI
- irgendwann ist dann auch das UI fertig

Als Anwender hat man es einfach, man "sieht" ja wenn das Menüband fertig da ist.
Die Testautomatsierung ist da etwas blind. Man sieht ein Control, es ist da und visible. Wenn man dann darauf klickt kommt es (je nach dem) zu Fehlern. Wenn der Fehler auftritt gibt es auch einen screenshot. Da sieht man dass das Menüband noch nicht voll da ist. Z.B. von Eingabefeldern sieht man schon einen Rahmen, aber noch keinen Inhalt.

Ich habe inzwischen mal versucht, das WM_PAINT abzufangen und am Ende das Fertig-Flag zu setzen. Ein Kollege meinte jedoch das macht man nicht. Das Problem habe ich an ihn übergeben. Nun ist ein Abfrage nach der Statemachine für die UI reingekommen. Mal schauen ob das langfristig hilft.