10sec Umfrage - Bitte um kurze Antwort!

[michael.herrmann]

Hi,

Ich entwickle eine GUI Automatisierungsbibliothek (http://www.getautoma.com) und weiß nicht, wie ich die Funktion, die Tastendrücke simuliert, nennen soll. Im Moment heißt sie 'type', was mit einer eingebauten Funktion kollidiert. Beispielverwendungen von meinem 'type':

Code: Alles auswählen

type(ENTER)

Code: Alles auswählen

type("Hello World!")

Code: Alles auswählen

type(CTRL + 'a')

Was wäre Eurer Meinung nach der beste andere Name für mein 'type'?

Meine Überlegungen bis jetzt: 'press' wäre kein schlechter Name, aber unsere Bibliothek erlaubt es auch, auf Buttons zu klicken. In dem Fall könnte der User dann glauben, er kann press("OK") verwenden. Eine Alternative wäre 'type_keys', das ist aber wieder recht lang und liest sich nicht gut bei zB type_keys(ENTER).

Vielen Dank!

[sparrow]

Warum erfindest du denn pywinauto neu?

[michael.herrmann]

Weil pywinauto einige Nachteile hat:
1) Es geht auf Applikations-interne IDs. Dies führt zu unleserlichen Automationsskripts, die schlecht wartbar sind. Außerdem funktionieren die Skripte dann nicht mehr, wenn sich die applikations-interne ID ändert.
2) Es erfordert viele waitFor-Befehle. Auch dies führt zu unleserlichen und unstabilen Skripts.

pywinauto's Beispiel:

Code: Alles auswählen

from pywinauto import application
app=application.Application()
app.start_('notepad.exe')
app.Notepad.MenuSelect('help->aboutnotepad')
app.aboutnotepad.OK.click()
app.notepad.edit.TypeKeys('Hello')
app.notepad.edit.TypeKeys('World')

Dasselbe Beispiel in Automa:

Code: Alles auswählen

start("Notepad")
click("Help", then="About Notepad")
click("OK")
type("Hello")
type("World")

mM nach viel besser lesbar. Außerdem kann Automa Dinge wie zB

Code: Alles auswählen

enter("test.txt", into="File name")

- anstatt über applikationsinterne IDs zu gehen wird hier nach einem Label "File name" und dann einem Textfeld (in dem Fall) rechts davon gesucht, wo der Text "test.txt" dann eingegeben wird. Genauso, wie es ein Mensch auch machen würde. Hierdurch sind die Skripts wie gesagt besser lesbar, einfacher zu schreiben, besser wartbar und robuster was Änderungen in der zu automatisierenden Applikation betrifft.

Danke für die Antwort auf jeden Fall. Was hältst du von meiner Erklärung? Habe ich dich überzeugen können?

[JonasR]

type fällt weg: http://docs.python.org/2/library/functions.html#type

[mutetella]

Wie wär's mit 'keypress'?

mutetella


EDIT: Dein Link führt ins nix... ;-(

[sparrow]

Ich mache mal weiter, wenn du gestattest. Ich arbeite relativ viel mit pywinauto und bin da manchmal in unvorhergesehene Fehler gelaufen.

Was ist mit Fenstern auf die man "warten muss"?
Ich habe hier zum Beispiel ein Programm dessen Eingabemaske ich automatisch befülle. Das Programm nimmt ganz viele Eingaben entgegen, dann gibt es eine Taste zum Bestätigen. Anschließend dauert es aber einen undefinierten Zeitraum bis das nächste Fenster erscheint, ein Dialogfeld in dem Einstellungen vorgenommen werden und anschließend bestätigt werden müssen. Die Zeit bis der Dialog kommt hängt davon ab, wie schnell die Prozesse im Hintergrund die Daten verwerten konnten.
Wie bekomme ich mit, dass der Dialog aufgetaucht ist?

[michael.herrmann]

Danke euch für die raschen Antworten!

@JonasR: Da steht, man sollte es nicht verwenden, aber dass es wegfällt steht da nicht, oder?

@mutetella: Danke für den Vorschlag. Was hältst du von den vier Optionen oben?
Bzgl der Seite: Haben angerufen; unser Hostingprovider hat anscheinend gerade beschlossen, die Datenbanken neu zu starten(!?!) Sollte jetzt wieder gehen.

@sparrow: Im Moment ist es so, dass Automa nach einer Aktion wartet, bis sich die CPU wieder beruhigt hat. Das funktioniert *erstaunlich* gut. Ich nehme mal an, dass die Prozesse im Hintergrund die Daten unter CPU-Utilisation verwerten, es ist also nicht unwahrscheinlich, dass das in Automa jetzt schon ohne explizitem Warten funktioniert. Wir werden in Zukunft wohl aber zusätzlich noch eine explizite waitFor-Aktion (oÄ) einführen, diese wird aber hoffentlich nur in sehr seltenen Fällen verwendet werden müssen!

[michael.herrmann]

Hm, anscheinend hat unser Provider immer noch Probleme mit dem Server - die Seite lädt, ist aber ziemlich langsam. Sorry

[michael.herrmann]

Hm, anscheinend hat unser Provider immer noch Probleme mit dem Server - die Seite lädt, ist aber ziemlich langsam. Sorry

Scheint jetzt wieder zu gehen

[sparrow]

type_keys ist wohl das, womit sich jeder Programmierer am ehesten anfreunden könnte.

Ich denke aber, dass der Markt mit pywinauto schon gut abgedeckt ist. Das Arbeiten auf den Prozess-IDs hat den Vorteil, das man sich recht schnell eine Liste der Fenster besorgen kann, die von diesem Prozess geöffnet wurden.

Über das Tool an sich: ich denke, dass pywinauto seine Sache wirklich gut macht. Im praktischen Einsatz hat es sich bewährt. Ob der Code schlechter wartbar ist? Schwierig zu sagen. Ich würde sagen, da nehmen sich beide Lösungen bisher nicht viel. Im Zweifelsfall würde ich auf das bewährte setzen.

[michael.herrmann]

@sparrow: Verstehe, danke für die Antwort. Was jemand anders grade noch vorgeschlagen hat: send_keys. Was hältst du davon? Würdest du es type_keys vorziehen? Es ist angeblich in andern Tools weiter verbreitet.

Was denken denn die Anderen darüber?

Danke für eure Hilfe!!

[sparrow]

Wenn man davon ausgeht, dass man einen Knopf drückt oder klickt, sehe ich das so, dass man eine Taste eher tippt als sendet.

[michael.herrmann]

Sehe ich auch so Aber vielleicht sieht das ja auch wer anders(?)

[BlackJack]

PEP8 empfiehlt bei Namenskollisionen einen Unterstrich anzuhängen, also `type_()`. Keine Ahnung ob das als Alternative in Frage kommt, oder eher komisch aussieht und die Leute zu Fehlern verleitet wie den Unterstrich wegzulassen und sich zu wundern warum ``type('some text')`` weder einen Fehler, noch eine Reaktion hervor ruft.

Bei `type*()` sehe ich im geistigen Auge jemanden Tippen, bei `press*()` dagegen eher die Taste(n) *drücken*, d.h. das könnte die Erwartung wecken, dass es auch eine Funktion gibt um die Taste(n) wieder *los zu lassen*.

[michael.herrmann]

Hm, das mit "press" ist ein guter Punkt...

Wie kritisch seht ihr denn als erfahrenere Python-Programmierer die Überladung von "type"? Stellt es euch da die Haare auf, weil ihr eine sehr andere Bedeutung gewöhnt seid, oder kann man sich da sowieso schnell darauf einstellen?

[BlackJack]

@michael.herrmann: Ist halt zur Fehlersuche oder beim erkunden von fremden APIs sehr nützlich den Typ von einem ”unbekannten” Objekt ermitteln zu können. Unerfahrene Programmierer verwenden es manchmal um auf Datentypen zu testen, wo man eher `isinstance()` verwenden sollte, wenn man sich einen Typtest nicht verkneifen kann.

[michael.herrmann]

@BlackJack: Hi, ja, ich weiß schon, wofür 'type' normalerweise gut und nützlich ist. Was mich interessieren würde ist welcher Befehlsname im Kontext von GUI-Automatisierung für euch am logischsten wäre. Wenn ich so direkt fragen darf: Hast du zB eine Präferenz?

[BlackJack]

@michael.herrmann: Nicht wirklich. Ausser das `type()` bei Python ausfällt.

[michael.herrmann]

OK Danke

[Sr4l]

Natürlich könnte man `type` überschreiben, aber dann würde in einem Editor das type farblich anders hervorgehoben als andere Befehle.

In dem Tutorial benutzt ihr enter und type. Was ist der unterschied?


Meine Favoriten wären: type, insert, type_text, insert_text, enter