Editbox nachträglich in TabControl verschieben

  • Frage: Ist es möglich, eine Editbox (oder Label, oder sonst ein Control) nachträglich in ein bereits kreiertes TabControl zu verfrachten?

    RTFM offenbarte mir dazu keine Möglichkeit.


    Wozu das gut sein soll?

    - Nun, der User soll das GUI zur Laufzeit umgestalten können. In gewissen Grenzen zumindest.

    Meine Oberfläche hat inzwischen so viele Inputboxen, dass ich gezwungen war, diese zum Teil (aber auch nur zum Teil) in TabControls zu verstauen.

    Deren Anordnung mag dem User aber nicht unbedingt schmecken. Er soll es daher selbst festlegen können, ob eine bestimmte Editbox in einem Tab sitzt, oder nicht. Und wenn ja, dann in welchem.


    Wer weiß Rat?

  • Danke für den superschnellen Rat, alpines! Allerdings klemmt es noch ...

    Ich kriege das Beispiel nicht so umgefrickelt, dass es das tut, was ich möchte. Also eine bereits existierende Inputbox innerhalb des selben Fensters in/aus einem Tab verschieben.


    Ich habe das Codebeispiel mal so geändert, dass es klarer wird, was ich vorhabe.


  • Verschieben kannst du die Controls in andere Tabs glaube ich nicht, aber du kannst sie löschen und anschließend neu erstellen.

    Die Zuweisung der Variablen kannst du so lassen wie sie ist, wenn du ein Control löscht und direkt im Anschluss ein neues erstellst, bekommt es die ID vom gelöschten Control.


    Du musst aber die Tabseite wechseln wenn du das Control löscht und neu erstellst (wenn du dich auf der Seite befindest wo es erstellt wird, oder ein Repaint senden.

  • Hmm, doch noch watt:

    Mir fehlt zum vollendeten Glück noch der Befehl zum Auslesen der Koordinaten der zu löschenden InputBox.


    Ich habe den Code mal entrümpelt und zwei Buttons plus Functions spendiert, um die InputBox gezielt in einen bestimmten Tab zu "verschieben".

    Das funktioniert auch, nur gehen mir die Koordinaten hops.

    Ich brauche das Gegenstück zu GUICtrlSetPos()


  • Danke Bitnugger!


    Der Vollständigkeit halber, falls es anderen Usern hilft, hier noch der lauffähige Code:


    Ich code, also bin ich!

    Einmal editiert, zuletzt von Code-Jack () aus folgendem Grund: Code aktualisiert

  • Jetzt gibt es noch eine kleine Unelegantheit ...


    Ich wollte es erreichen, dass die aus dem sichtbaren Tab gelöschte InputBox dort auch tasächlich sofort verschwindet, ohne dass man dazu erst manuell die Tabreiter umschalten müsste.

    _GUICtrlTab_SetCurSel() ist hier mein Freund, dachte ich ...

    Doch da gibt es eine Sonderbarkeit:

    Die Zeile 57 ist erforderlich, damit Zeile 58 ihren erwarteten Dienst tut. Komisch.


    Aber noch komischer: Die umgekehrte Richtung funzt gar nicht.

    Die Zeilen 74 bis 76 kann ich vertauschen und auskommentieren wie ich will - Tab 1 wird nicht selektiert.

    Dabei liefert mir ein testweise als 78. Zeile hintendran gehängtes:

    ConsoleWrite("Current Selection: " & _GUICtrlTab_GetCurSel($idTabCtrl))

    erwartungsgemäß Das Resultat "1".

    Trotzdem erfolgt keine Umschaltung auf Tab 1, wenn zuletzt Tab 2 aktiv war.

  • _GUICtrlTab_SetCurSel() ist hier mein Freund, dachte ich ...

    Doch da gibt es eine Sonderbarkeit:

    Die Zeile 57 ist erforderlich, damit Zeile 58 ihren erwarteten Dienst tut. Komisch.

    $iIndex 0-based item index

    :rolleyes :

    _GUICtrlTab_SetCurSel($idTabCtrl, 1)
    _GUICtrlTab_SetCurSel($idTabCtrl, 2)

    _GUICtrlTab_SetCurSel($idTabCtrl, 2)
    _GUICtrlTab_SetCurSel($idTabCtrl, 1)

  • OK, das ist natürlich ein Argument, dem ich nichts engegen setzen kann. ;-)

    - Nun funktioniert es.

    Dein :rolleyes: ist somit voll berechtigt; ich setze mir ganz kleinlaut die Eselsmütze auf und schäme mich: <:-(


    Thema nun wirklich erledigt. Danke alpines! :thumbup:

  • Ergänzend möchte ich noch sagen, dass derjenige Tab, in den man zuletzt ein GUI-Element verschoben hatte, irgendwie "klebrig" ist.

    Erstellt man nämlich im Anschluss ein neues Editfeld etc., so landet dieses wiederum im Tab, auch wenn man es doch eigentlich im Hauptfenster haben wollte.


    Per GUISwitch() lässt sich das auch nicht abstellen.

    Was hingegen Abhilfe schafft:

    Zuletzt diese Zeile ausführen:


    GUICtrlCreateTabItem("")


    - Die hat man zwar typischerweise schon an anderer Stelle stehen, nämlich am Ende des Codes, der das TabControl kreierte, aber man kann die Zeile auch mehrfach im Quelltest einfügen, nämlich überall da, wo man nach dieser GUISwitcherei das TabControl wieder "deselektieren" möchte.


    Vielleicht hilft der Tipp ja mal jemandem.

  • Ja alpines, genau das sind die vielen Kleinigkeiten, die einen Einsteiger ausbremsen.

    Du hast es schon in der ersten Antwort erwähnt und ich hatte mir natürlich auch die englische Hilfedatei zur Brust genommen und bei GUISwitch nachgeschaut.

    Aus den für meinen Geschmack etwas spärlichen Informationen zu GUISwitch ging für mich aber nicht hervor, dass man den Befehl, um den es geht, noch ein weiteres Mal im Code platzieren muss.

    Ich dachte, er müsste lediglich nach dem Kreieren der Tabelle angewendet werden und das war bei mir ja eh schon der Fall; hielt den Punkt daher für abgehakt.


    Du hattest den Hilfe-Eintrag zu GUICtrlCreateTabItem verlinkt. Dort ist es tatsächlich explizit für GUISwitch erwähnt, dass man die Struktur "once again" abschließen soll.

    Dieser Hinweis wäre in der Hilfedatei meiner Meinung nach deutlich besser im Eintrag zu GUISwitch aufgehoben.

    Ich finde den Hilfe-Eintrag zu GUISwitch nicht nur spärlich, sondern sogar missverständlich.


    Dabei - und das ärgert mich im Nachhinein - ist GUICtrlCreateTabItem("") dort im Codebeispiel tatsächlich doppelt vorhanden.

    Das fällt einem nur nicht ins Auge, wenn man es gar nicht auf dem Plan hat, dass dieser Befehl von Bedeutung ist, für das was man vorhat.

    Dem Codebeispiel fehlt nämlich genau das, worum es mir zuletzt ging: Nach dem Switchen wieder außerhalb des TabControls weiter zu machen und neue GUI-Elemente dort außerhalb zu platzieren.


    Das sind Fallstricke, die Ihr erfahrenen Superprogrammierer vermutlich schon gar nicht mehr wahrnehmt.

    Aber einem Einsteiger macht es halt das Leben schwer.


    Für viel wichtiger, als die bloße Übersetzung der Hilfedatei auf Deutsch, würde ich daher eine Ausschmückung halten.

    Also ausführlichere Texte und brauchbarere Codebeispiele, die wirklich vollumfanglich das zeigen, was von Bedeutung ist.

  • Du hattest den Hilfe-Eintrag zu GUICtrlCreateTabItem verlinkt. Dort ist es tatsächlich explizit für GUISwitch erwähnt, dass man die Struktur "once again" abschließen soll.

    Dieser Hinweis wäre in der Hilfedatei meiner Meinung nach deutlich besser im Eintrag zu GUISwitch aufgehoben.

    Ich finde den Hilfe-Eintrag zu GUISwitch nicht nur spärlich, sondern sogar missverständlich.

    GUISwitch:

    Englische Hilfe: Using the tabitemID allow to create new control in the specified tabitem control. Don't forget to close tabitem definition GUICtrlCreateTabItem("")

    Deutsche Hilfe: TabitemID ist zu benutzen, um neue Controls in dem angegebenen tabitem zu erstellen. Es darf nicht vergessen werden, das tabitem mit der Funktion GUICtrlCreateTabItem("") zu schließen.


    GUICtrlCreateTabItem:

    Englische Hilfe: It is important to close the tab structure by creating a final tabitem control with a null text - GUICtrlCreateTabItem("").

    Deutsche Hilfe: Es ist wichtig die Tab-Struktur mit einem TabItem-Control mit leerem Text abzuschließen - GUICtrlCreateTabItem("")


    Also einen Fallstrick würde ich das nicht bezeichnen, in den Remarks/Bermerkungen steht es ja. Wenn man das nicht liest kann man es halt nicht wissen, da kann man noch so erfahren sein.

  • Ja, ich habe die Sachen ja gelesen. Habe viel RTFM gemacht.

    Aber ich finde es noch immer missverständlich. Denn ich hatte das TabItem ja brav geschlossen ... halt nachdem die Tabelle kreiert wurde ... :-)


    # Don't forget to close tabitem definition GUICtrlCreateTabItem("")

    - Hatte ich ja artig gemacht. Jedenfalls so, wie ich diesen Text verstanden hatte; also nach der "tabitem definition".


    # Es darf nicht vergessen werden, das tabitem mit der Funktion GUICtrlCreateTabItem("") zu schließen.

    - War ja - wie ich dachte - längst gemacht, gleich nach dem Kreieren der Tabelle. Sache für abgehakt befunden!


    # It is important to close the tab structure by creating a final tabitem control with a null text - GUICtrlCreateTabItem("").

    - Aber sowatt von, hatte ich die "tab structure" geschlossen! Gleich nach dem Kreieren! Abgehakt!


    # Es ist wichtig die Tab-Struktur mit einem TabItem-Control mit leerem Text abzuschließen - GUICtrlCreateTabItem("")

    - Hey, ich bin hier der König des "Tab-Struktur-Schließens"! (Nach dem Kreieren der Tabelle ...)


    Alpines, ich hatte wirklich brav RTFM gemacht. Aber ich finde die Erklärungen in den Hilfedateien noch immer nicht klar genug.

    All diese diversen Erwähnungen von "structure" und "defination" hatte ich überhaupt nicht mit der Verwendung von GUISwitch in Verbindung gebracht, sondern (natürlich?) mit dem Erstellen der Tabelle.

    Beim Erstellen hat man es mit "Struktur" zu tun und muss sonstwas "definieren". Aber doch nicht beim bloßen Switchen ...


    Wenn ich bloß zu doof war und das einsehe, dann gebe ich das auch zu.

    Aber hier finde ich die Hilfedateien wirklich reichlich supotimal. Die Texte sind nicht präzise und unmissverständlich formuliert, sondern sie sind so oder so interpretierbar. Aber kaum korrekt interpretierbar, ohne sich das schön zu reden.

    Würde dort nicht so viel von "defination" und "structure" stehen, sondern klar und deutlich, dass man nach der Anwendung von _GUISwitch() wieder zum Fenster zurück "switchen" kann, indem man GUICtrlCreateTabItem("") anwendet, dann hätte gar kein Missverständnis entstehen können - das mich hier wohl gute 2-3 Stunden gekostet hatte.


    Ich schreibe das ja nicht, um zu nörgeln, sondern ich bedaure es, wenn AutoIt wegen solcher Sachen ein unverdientes Schattendasein fristet.

    Es sind diese scheinbaren Kleinigkeiten, die massiv Zeit kosten.

    Der Kopf ist voller guter Ideen, die nach Umsetzung schreien, aber dauernd klemmt es - woraufhin dann jedes Mal eine ziemliche Orgie von RTFM, Googelei und Forendurchforstung folgt.

    - Womöglich weiterhin gefolgt, von einer kleinlauten Frage hier im Forum, nachdem alles RTFM und alle Codetests nicht fruchteten.


    Ihr macht Euch hier im Forum die lobenswerte Mühe, die englische Hilfe auf Deutsch zu übersetzen. Und das, obwohl Ihr selbst das Resultat sicher längst nicht mehr benötigt. Ihr tut das also eher aus Altruismus, um Einsteigern zu helfen. Daumen hoch dafür!

    Jetzt komme ich (forgeschrittener Einsteiger, "Gelbgurt") und stoße Euch mit der Nase auf Stellen, wo es für Neulinge echt klemmen kann.

    Betrachtet meine Ausführungen daher bitte als konstruktive Hinweise, nicht als Nörgelei.

  • Alpines, ich hatte wirklich brav RTFM gemacht. Aber ich finde die Erklärungen in den Hilfedateien noch immer nicht klar genug.

    Hilfe und Dokumentation schreiben ist schon eine Kunst für sich.


    Auch wenn es nicht implizit davon herausgeht so kann man es sich um ein paar Ecken denken, denn wenn ich switche bin ich ja praktisch in dem Zustand wo ich gerade die TabSeite neu erzeugt habe und Controls hinzufüge, und wenn man sowas macht, dann setzt man ja immer ein GUICtrlCreateTabItem("") drunter. Dass das suboptimal formuliert ist, liegt wohl auf der Hand.


    Falls dich sowas wirklich stört kannst du dazu gerne in den entsprechenden Hilfe-Threads was dazu posten, wir sorgen schon dafür, dass in den nächsten Hilfeversionen (auch die aktuelle Online-Hilfe) dann geupdatet wird, damit solche Missverständnisse in Zukunft nicht mehr auftreten.

  • Ich habe dein Script aus Post #8 mal ein wenig geändert und erweitert, damit bei der neu erstellten InputBox auch die Styles und ExStyles erhalten bleiben.


    Soweit funktioniert das auch alles, wie es soll.


    Bei Drag-n-Drop auf die InputBox ist mir allerdings ein Fehler aufgefallen... denn immer bei der jeweils ersten Aktion (nach dem Erstellen der InputBox) wird das Drop-File vor dem bereits vorhandenen Inhalt der InputBox eingefügt, bei jeder weiteren Aktion nur noch das Drop-File, obwohl in allen Fällen der vorbelegte Text in der InputBox steht.


    Edit: Obiger Fehler bei Drag-n-Drop bezieht sich auf Windows 10. Auf Windows 7 werden in allen Fällen die letzten beiden Zeichen des vorbelegten Texts in der InputBox abgeschnitten und das Drop-File dann dahinter eingefügt.


  • Falls dich sowas wirklich stört kannst du dazu gerne in den entsprechenden Hilfe-Threads was dazu posten, wir sorgen schon dafür, dass in den nächsten Hilfeversionen (auch die aktuelle Online-Hilfe) dann geupdatet wird, damit solche Missverständnisse in Zukunft nicht mehr auftreten.

    Danke alpines!

    Und ja, Du hast Recht, es ist wirklich eine Kunst, eine "für Dumme" taugliche Anleitung zu schreiben. Denn dem Aotor, der eine Anleitung schreibt, sind die "trivialen" Zusammenhänge ja sonnenklar. Der kommt kaum auf die Idee, dabei Probleme zu erwarten.

    Ich werde dann künftig in den Hilfe-Threads meine Vorschläge einreichen.




    Ich habe dein Script aus Post #8 mal ein wenig geändert und erweitert, damit bei der neu erstellten InputBox auch die Styles und ExStyles erhalten bleiben.

    Danke Bitnugger!

    Ich hatte es zuletzt für mich bereits so umgesetzt, dass die Styles etc. erhalten bleiben und alles fehlerfrei funzt.

    Mein Codebeispiel war ja speziell fürs Forum auf das Minimum kastriert.


    Ich teste hier zunächst nur unter Windows XP. Da läuft mein (voller) Code einwandfrei.

    Die Tests unter höheren Windows-Versionen kommen bei mir erst später an die Reihe.

    Gut dass Du darauf aufmerksam machst, dass da eventuell Probleme zu erwarten sind!

  • Gut dass Du darauf aufmerksam machst, dass da eventuell Probleme zu erwarten sind!

    Nein, keine Probleme, denn die Lösung ist recht simpel: Du musst die Message WM_DROPFILES selbst verarbeiten.


    So sieht das dann aus...