Inputbox Dialog Idee gesucht

    Hallo,

    ich nutze das „ISN Autoit Studio“ mit dem GUI Modul.

    Ich möchte die AutoIt-Inputbox durch eine eigene GUI (isf-Datei) ersetzen, u.a. wegen der Schriftgröße und mehrerer unterschiedlicher Eingabezeilen und Button.

    Ich möchte so viel wie möglich Code in die input.au3 und die input.isf auslagern und in unterschiedlichen Projekten wieder verwenden.

    (1) Was wäre aus Eurer Sicht die einfachste Datenübergabe von der input-au3 zu der Haupt-au3? Mir fallen nur die Zwischenablage (störanfällig) und Dateispeicherung (aufwendig) ein.

    Wie wäre eine Variablenübergabe von der input-au3 zur Haupt-au3 möglich?

    (2) Gibt es einen besseren Weg, als von der Haupt-au3 Datei mit der ShellExecuteWait die input-au3 aufzurufen, um den Input-Dialg der GUI anzuzeigen?

    (3) Gibt es im Forum bereits lauffähige Beispiele als Anregung? (konnte keine finden, die auf au3 / isf Dateien basieren ... ISN )

    (4) Was wäre Eurer Meinung ein flexibler Weg, um das Grundgerüst mit wenigen Änderungen in vielen Projekten zu verwenden?

    Danke für Eure Anregungen und Beispiele.

    1) Du bindest deine au3 doch so oder so per include ein, also einfach die Funktion aus deiner au3 aufrufen und beim Funktionsaufruf die Parameter übergeben (Haupt au3 zu deiner inout-au3 funktion) wie bei jeder anderen Funktion auch. Und das Return macht die Datenübergabe (Ergebnis) wieder in die andere Richtung.

    2) siehe 1. (include + Funktionsaufruf)

    3) includes gibt es so gut wie in jedem Projekt, also auch genug Beispiele

    4) siehe 1.

    2 Mal editiert, zuletzt von Moombas (22. Februar 2022 um 10:17)

    Hi Banana_2_Day ,

    da ich ISN AutoIt Studio nicht als Editor nutze, bin ich hierbei sicherlich nicht der richtige Ansprechpartner.
    Dies ist wohl eher ISI360 😇 .

    Ich melde mich nur weil mir dein beschriebenes Szenario danach klingt, dass du in deinem "Haupt-au3" Skript, die "input-au3" per #include "input-au3" einbindest (und fertig).

    Vielleicht liege ich auch völlig falsch, dass wird ISI360 sicherlich aufklären, doch an sich ist ein modularer Aufbau, bei dem du GUI von Actions (Funktionen der Business Logik als Beispiel) trennst, zu empfehlen.

    Mich würde mal deine Projekt-Struktur 📋 interessieren, damit ich bzgl. der Idee zum ISN AutoIt Studio dazulernen kann, doch dies vielleicht besser an anderer Stelle im Gespräch mit ISI 😀 .

    Viele Grüße
    Sven

    Zitat von Moombas

    1) Du bindest deine au3 doch so oder so per include ein, also einfach die Funktion aus deiner au3 aufrufen und beim Funktionsaufruf die Parameter übergeben (Haupt au3 zu deiner inout-au3 funktion) wie bei jeder anderen Funktion auch. Und das Return macht die Datenübergabe (Ergebnis) wieder in die andere Richtung.

    Nein.

    Ich binde die input.au3 per "ShellExecuteWait" ein, nicht per include - wie in Post 1 in Punkt (2) geschrieben.

    Grund = Problem:

    Wenn ich die input-au3 mit include einbinde, wird die GUI aufgerufen und der Code in der Haupt-au3 weiter abgearbeitet.

    Wie kann ich den Code in der Haupt-au3 so lange pausieren lassen, so lange die input.au3 läuft?

    ... ich habe bisher im Forum kein Beispiel auf Basis von ISN gefunden.

    Und danke für Eure Antworten. Finden wir eine Lösung.

    Dann machst du einen Fehler aus meiner Sicht in deiner input au3

    Dort dürfen nur die Funktionen stehen, diese aber niemals ausgeführt werden. Das machst du in deiner Haupt au3

    Einmal editiert, zuletzt von Moombas (24. Februar 2022 um 08:17)

    Moin,

    soweit ich es verstanden habe, generiert das ISN Studio GUI-Code und verpackt zumindest den größten Teil davon zusammen mit den Metadaten in .ISF Dateien. Wenn Du Dir die anschaust, findest Du u.a. auch den Code, den Du hättest selber schreiben müssen, um das Fenster zu erstellen. Du könntest den nutzen, um das Fenster in eine eigene Funktion zu packen, die im Hauptskript aufgerufen wird und die benötigten Werte zurückgibt.

    Wenn Dein Fenster nicht allzu viele 'komplizierte' Controls enthält, sollte das selbst für einen GUI-Anfänger nicht zu schwer sein.

    Zitat von Velted

    Wenn Dein Fenster nicht allzu viele 'komplizierte' Controls enthält, sollte das selbst für einen GUI-Anfänger nicht zu schwer sein.

    Das Fenster enthält "komplizierte" Controls, daher auch die ISN Nutzung, mit der das fehlerfreier geht.

    Ich pausiere das Thema, bis ich den Kopf dafür frei habe und bei ISN direkt nachfragen kann. Es gibt einen Knoten, den ich erst entwirren muss.

    Ich möchte dabei nochmal auf meine Post #5 hinweisen.

    Binde deine GUI-Funktion per include der AU3 ein (ohne sie dort aufzurufen!!).

    Und den Aufruf machst du dann aus der Mainform wie mit jeder anderen Funktion.

    Zitat von Banana_2_Day

    Das Fenster enthält "komplizierte" Controls, daher auch die ISN Nutzung, mit der das fehlerfreier geht.

    Nicht falsch verstehen, aber hier zeigt sich m.M. nach der Nachteil von IDE's, die dir versuchen das Denken abzunehmen.

    Wenn du dir z.B. nicht bewusst bist, welche Flags oder Flagkombinationen du setzen musst, um ein bestimmtes Aussehen / Verhalten deiner Controls zu erreichen, dann geht dir hier auch ein Lerneffekt verloren. weil du es beim nächsten mal wieder nicht weißt.

    Um erstmalig eine GUI zu erstellen ist das für einen Anfänger durchaus eine gute Hilfe. Aber auch da ist derjenige gefordert hinterher zu schauen: Welcher Code wurde mir generiert und was passiert dabei?

    Und früher oder später verabschiedest du dich sicher auch von GUI-Erstellungs-Tools. Ich gehe nach jahrelanger Forumserfahrung davon aus, dass 95% der wirklich aktiven AutoIt-Nutzer ihre GUI händisch erstellen. Denn selbst wenn ich nur mal eben eine Test-GUI benötige, ist diese per Hand deutlich schneller erstellt, als mit einem Tool.

    Zitat von BugFix

    Nicht falsch verstehen, aber hier zeigt sich m.M. nach der Nachteil von IDE's, die dir versuchen das Denken abzunehmen.

    ...

    Um erstmalig eine GUI zu erstellen ist das für einen Anfänger durchaus eine gute Hilfe. Aber auch da ist derjenige gefordert hinterher zu schauen: Welcher Code wurde mir generiert und was passiert dabei?

    Bezüglich autoit stimme ich da Bugfix zu, nutze aber in Autoit kaum GUI.

    Meine Erfahrung bei anderen Sprachen/Programmen ist da jedoch anders, da dort der eigentliche Programm-Code vom GUI-Code explizit getrennt ist und per Programm-Code angesprochen wird. Also im Prinzip, wie man das hier auch (wie bereits mehrfach angesprochen) mit jedem include auch macht.