UDF mit interner GUI-Verabeitung für GuiGetMsg- und OnEvent-Mode einsatzfähig -- wie macht ihr es?

  • Bei UDF's möchte man ja erreichen, dass möglichst viel in den UDF-Funktionen abläuft und der User dort nicht aktiv werden muss.

    Bei Verwendung von grafischen Oberflächen erspart einem der OnEvent-Mode oft viel Schreibarbeit, einige Dinge lassen sich auch nur sinnvoll mit dem OnEvent-Mode lösen.

    Nun kann ich ich natürlich festlegen: Anwendung dieser UDF ausschließlich im OnEvent-Mode.

    Oder der User muss mir die Events zum Prüfen in die UDF weiterleiten (so, wie in meinem Bsp. unten).

    Eine Möglichkeit wäre wohl auch, dass ich mich direkt in den Nachrichtenstrom des Userfensters einklinke und darüber auswerte. Wie handhabt ihr das so?


    Hier mein Funktionsbeispiel

    Die UDF:

    Die Anwendung:

  • Hey BuxFix,

    hast du Schoneinmal eine Zweite Laufzeit in Betracht gezogen?

    Ich meine, ja es ist Sau umständlich und immer schwierig umzusetzen. Aber die Performance macht das dann bestimmt wieder wett.
    Vielleicht via Child Prozess, mit Vollzugriff auf den Prozess, und dann so einen Kommunikationsweg öffnen.
    Es gibt ja einige Wege, die einfachen sind oft nicht effizient/zuverlässig genug.

    Wenn man fragen darf, welchen Funktionsumfang soll die UDF denn übernehmen?

    Lieben Gruß

    M

  • Ich persönlich würde prinzipiell erst gar nicht mit den AutoIt Funktionen arbeiten für eine allgemeine UDF. Du kannst schlicht und einfach die WinAPI Funktionen verwenden und entsprechend auch die Event Queue abfragen. Aber ehrlich gesagt habe ich Probleme nachzuvollziehen wieso du dir überhaupt Gedanken um die AutoIt Event Modis machst. Für was soll die UDF denn ausgelegt werden, bzw. Worauf bist du konkret gestoßen dass du dir überhaupt diesen Gedanken machst da eine Unterscheidung machen zu müssen?


    Kann aber auch sein dass ich zu lange nicht mehr in AutoIt programmiert habe um die Gründe deiner Fragestellung zu vestehen. ^^

  • Worauf bist du konkret gestoßen dass du dir überhaupt diesen Gedanken machst da eine Unterscheidung machen zu müssen?

    Hmm, ich hatte eigentlich gedacht, dass mein Code-Bsp. das recht verständlich aufzeigt.

    Ich versuche nochmal das zu abstrahieren:

    Die UDF beinhaltet Funktionen, mit denen der Anwender GUI-Elemente in seiner GUI erstellt. Diese Ctrl haben durch die UDF festgelegte Eigenschaften, die von den Standards abweichen. Zu diesem Zweck muss die Auswertung dieser Ctrl auch innerhalb der UDF passieren, da sonst die UDF-spezifischen Eigenschaften der Ctrl nicht zum Tragen kommen.

    Und da spielt es schon eine Rolle, welcher Event-Modus genutzt wird. Die alternative Nutzung des direkten Message Queues hatte ich ja ebenfalls als Möglichkeit erwähnt.

  • Eine Möglichkeit wäre wohl auch, dass ich mich direkt in den Nachrichtenstrom des Userfensters einklinke und darüber auswerte.

    Für mich die effizienteste Methode... mit geringstem Aufwand für beiden Seiten... zumal du so auch die Kontrolle darüber hast, welche Nachrichten an den User weitergeleitet werden.


    Einen Haken gibt es hier allerdings auch... wenn der User ebenfalls einen Hook verwenden will, um die Nachrichten für die WinProc umzuleiten... denn dann stürzt AutoIt ab. Meine auch irgendwo gelesen zu haben, das laut Microsoft pro Thread nur ein Hook zum Umleiten der WinProc erlaubt ist.


    So stürzt AutoIt ab...

    Code
    Return _WinAPI_CallNextHookEx($g_hHook, $nCode, $wParam, $lParam)

    ...doch so funktioniert es "seltsammerweise"!

    Code
    Return _WinAPI_CallNextHookEx($g_hHook, $nCode, $wParam, $lParam)[0]