Hallo Leute. Hat jemand einen Einstellungen-/Settings-Dialog, den er mit uns teilen möchte?
Der Dialog sollte einfach zu ändern und zu erweitern sein, am besten z. B. mit Koda erstellt, sodass man ihn visuell bearbeiten kann.
Alle Vorschläge sind willkommen, solange sie, wie gesagt, einfach zu warten sind. 
Guck mal in die Settings von Koda, allerdings hast du dafür glaube ich keine editierbaren Dateien um das Design direkt zu übernehmen.
Alternativ kannst du dir auch die Settingsforms von deinem Lieblingsprogramm PassIt2 herunterladen.
Im src-Download sind diese enthalten, vielleicht ist es ja was für dich.
Guck mal in die Settings von Koda, allerdings hast du dafür glaube ich keine editierbaren Dateien um das Design direkt zu übernehmen.
Wie kann ich das denn in meinem Programm als Settings-Dialog benutzen? Ich glaub ich steh gerade auf der Leitung. 
Wie kann ich das denn in meinem Programm als Settings-Dialog benutzen?
Wie ich bereits schrieb gibts dafür keine Dateien die mir bekannt wären, ich sprach vom Aufbau per se.
Sollte nicht allzuschwierig sein die paar Ctls zu kopieren.
Nachgehakt: Hat jemand Code für einen Einstellungen-/Settings-Dialog, den er teilen möchte? 
Wenn es nicht fix sein soll, ist die einfachste Lösung ein Treeview mit Checkboxen.
Kannst du jederzeit beliebig verändern.
Ich arbeite da nun schon seit Stunden dran, links eine ListBox, rechts Versuche mit: Tab-Control, Child-GUIs, ein Tab-Control mit einem Child-GUI, das die Tabs oben (die Reiter) verdeckt, aber nichts will so ausehen, wie in den Screenshots.
Dein Vorschlag hört sich interessant an. Hast du Code, den du teilen würdest?
Bin gerade nicht am PC, aber suche mal im EN Forum nach "TreeviewTab".
Ich habe mal eine GUI erstellt, die so wie Deine Vorgabe aussieht.
Auf der rechten Seite befinden sich Child-Fenster, die mit einem Klick auf eines der Treeview-Items ein-/ausgeblendet werden.
#include <GUIConstantsEx.au3>
#include <GuiTreeView.au3>
#include <TreeViewConstants.au3>
#include <WindowsConstants.au3>
Global $hMainGui = GUICreate('Test', 600, 380)
GUISetBkColor(0xAAAAAA)
GUICtrlCreateLabel('', -2, 50, 604, 4, -1, $WS_EX_CLIENTEDGE)
GUICtrlCreateLabel('', -2, 350, 604, 4, -1, $WS_EX_CLIENTEDGE)
GUICtrlCreateLabel('', 170, 54, 4, 300, -1, $WS_EX_CLIENTEDGE)
Global $idHeaderIcon = GUICtrlCreateIcon('shell32.dll', -131, 5, 5, 40, 40)
Global $idHeaderText = GUICtrlCreateLabel('Sample GUI', 50, 10, 200, 28)
GUICtrlSetFont(-1, 16, 600, 0, 'Arial', 4)
Global $idTreeview = GUICtrlCreateTreeView(10, 60, 160, 200, BitOR($TVS_DISABLEDRAGDROP, $TVS_SHOWSELALWAYS))
GUICtrlSetBkColor(-1, 0xAAAAAA)
GUICtrlSetFont(-1, 12, 600, 0, 'Arial', 4)
Global $idLink1 = GUICtrlCreateTreeViewItem('Link 1', $idTreeview)
_GUICtrlTreeView_SetIcon($idTreeview, $idLink1, 'shell32.dll', 43)
Global $idLink2 = GUICtrlCreateTreeViewItem('Link 2', $idTreeview)
_GUICtrlTreeView_SetIcon($idTreeview, $idLink2, 'shell32.dll', 166)
Global $idLink3 = GUICtrlCreateTreeViewItem('Link 3', $idTreeview)
_GUICtrlTreeView_SetIcon($idTreeview, $idLink3, 'shell32.dll', 221)
Global $idLink4 = GUICtrlCreateTreeViewItem('Link 4', $idTreeview)
_GUICtrlTreeView_SetIcon($idTreeview, $idLink4, 'shell32.dll', 21)
Global $hLink1Gui = GUICreate('', 415, 285, 180, 60, $WS_CHILD, -1, $hMainGui)
GUISetBkColor(0xAAAAFF)
GUICtrlCreateLabel('Title for the panel 1', 50, 10, 200, 28)
GUICtrlSetFont(-1, 14, 600, 0, 'Arial', 4)
GUICtrlCreateLabel('Label1', 10, 44, 80, 28)
GUICtrlSetFont(-1, 12, 400, 0, 'Arial', 4)
Global $idInput1 = GUICtrlCreateInput('', 90, 40, 200, 28)
Global $idButton1 = GUICtrlCreateButton('Button1', 320, 40, 80, 28)
Global $hLink2Gui = GUICreate('', 415, 285, 180, 60, $WS_CHILD, -1, $hMainGui)
GUISetBkColor(0xAAFFFF)
GUICtrlCreateLabel('Title for the panel 2', 50, 10, 200, 28)
GUICtrlSetFont(-1, 14, 600, 0, 'Arial', 4)
GUICtrlCreateLabel('Label2', 10, 44, 80, 28)
GUICtrlSetFont(-1, 12, 400, 0, 'Arial', 4)
Global $idInput2 = GUICtrlCreateInput('', 90, 40, 200, 28)
Global $idButton2 = GUICtrlCreateButton('Button2', 320, 40, 80, 28)
Global $hLink3Gui = GUICreate('', 415, 285, 180, 60, $WS_CHILD, -1, $hMainGui)
GUISetBkColor(0xFFAAAA)
GUICtrlCreateLabel('Title for the panel 3', 50, 10, 200, 28)
GUICtrlSetFont(-1, 14, 600, 0, 'Arial', 4)
GUICtrlCreateLabel('Label3', 10, 44, 80, 28)
GUICtrlSetFont(-1, 12, 400, 0, 'Arial', 4)
Global $idInput3 = GUICtrlCreateInput('', 90, 40, 200, 28)
Global $idButton3 = GUICtrlCreateButton('Button3', 320, 40, 80, 28)
Global $hLink4Gui = GUICreate('', 415, 285, 180, 60, $WS_CHILD, -1, $hMainGui)
GUISetBkColor(0xAAFFAA)
GUICtrlCreateLabel('Title for the panel 4', 50, 10, 200, 28)
GUICtrlSetFont(-1, 14, 600, 0, 'Arial', 4)
GUICtrlCreateLabel('Label4', 10, 44, 80, 28)
GUICtrlSetFont(-1, 12, 400, 0, 'Arial', 4)
Global $idInput4 = GUICtrlCreateInput('', 90, 40, 200, 28)
Global $idButton4 = GUICtrlCreateButton('Button4', 320, 40, 80, 28)
Global $hLastGui = 0
GUISetState(@SW_SHOW, $hMainGui)
While True
Switch GUIGetMsg()
Case $GUI_EVENT_CLOSE
Exit
Case $idLink1
If $hLastGui <> 0 Then GUISetState(@SW_HIDE, $hLastGui)
GUISetState(@SW_SHOW, $hLink1Gui)
$hLastGui = $hLink1Gui
Case $idLink2
If $hLastGui <> 0 Then GUISetState(@SW_HIDE, $hLastGui)
GUISetState(@SW_SHOW, $hLink2Gui)
$hLastGui = $hLink2Gui
Case $idLink3
If $hLastGui <> 0 Then GUISetState(@SW_HIDE, $hLastGui)
GUISetState(@SW_SHOW, $hLink3Gui)
$hLastGui = $hLink3Gui
Case $idLink4
If $hLastGui <> 0 Then GUISetState(@SW_HIDE, $hLastGui)
GUISetState(@SW_SHOW, $hLink4Gui)
$hLastGui = $hLink4Gui
EndSwitch
WEndHat ein bisschen gedauert, denn ich habe vieles probiert, um einen Weg zu finden, die gewünschten Eigenschaften zu erhalten: Der Dialog sollte einfach zu ändern und zu erweitern sein, am besten z. B. mit Koda erstellt, sodass man ihn visuell bearbeiten kann.
Das ISN Studio hat viele Möglichkeiten, aber leider finde ich die Bedienung nicht intuitiv. Es dauert einfach viel zu lange, bis ich da verstehe, wie es funktioniert. Nach einer halben Nacht Einarbeitung habe ich das aufgegeben.
Koda verblüfft mich immer wieder positiv! Da habe ich das Gefühl, das Programm intuitiv bedienen zu können. Insbesondere die visuelle Handhabung der Controls ist mir von Visual Basic 6.0 (VB Classic) sehr vertraut. Das ist ansich mein Favorit. - Leider wurde die Entwicklung schon vor etwa 10 Jahren eingestellt und einige neuere Dinge werden nicht unterstützt.
Nun habe ich eine weitere Nacht an einem Konzept gearbeitet, mit dem ein Settings-Dialog mit visueller Unterstützung von Koda gehandhabt werden kann. Ziel ist es nicht nur, einen Settings-Dialog 1 Mal zu erstellen, sondern auch in einem halben Jahr problemlos laden und visuell erweitern/ändern zu können.
Das von dir genannte TreeViewTab sieht wirklich chick aus! Nachdem ich doch eine Weile gebraucht habe, um die Handhabung zu verstehen, denke ich, man könnte mit Koda die Controls der Tab-Seiten erstellen/verwalten und mit der TreeViewTab UDF verwenden. Um da weiter Arbeit reinzustecken, bräuchte ich aber die Möglichkeit, die Farbe von allen Teilen der GUI ändern zu können. Einige Teile sind leicht zu färben, aber den großen Hauptbereich konnte ich bisher nicht färben. Hast du eine Idee, wie man das machen könnte?
Dein Settings-Dialog sieht dem anderen verblüffend ähnlich. 
Der Code ist bei beiden Lösungen einfach gehalten und ich denke, auch hier könnte man mit ein wenig Aufwand die einzelen Tab-Seiten mit Koda erstellen und warten.
Dein Code hat mir allerdings noch viel mehr geholfen! Damit konnte ich ein Rätsel lösen, bei dem das Child-GUI dem Parent-GUI den Focus gestohlen hat. Meine ersten beiden Ideen waren zum einen das, was du umgesetzt hast, zum anderen wollte ich ein Tab-Control benutzen und die Tab-Reiter (die kleinen Rechtecke oben am Tab-Control) mit einem Child-GUI abdecken. Leider hatte bei meiner Umsetzung das Child immer den Focus vom Parent-GUI weggenommen. Beim Klick auf das Child wurde die Titelleiste deaktiviert dargestellt. Des Rätsels Lösung war die Erstellung des Child-GUIs im Style statt im ExStyle! Ich hatte ExStyle $WS_EX_MDICHILD benutzt, was die Probleme verursachte. Als ich stattdessen $WS_CHILD im Style benutzte, hat's geklappt. (Kaum macht man was richtig, schon funktionierts!) 
Nun kann ich weiter überlegen, wie ich die visuelle Handhabung mit Koda und die besonderen Ansprüche mit Child-GUIs unter einen Hut bekomme. Ideen sind willkommen!
Vielen Dank an euch beide!
Prof Bernd.
Nun kann ich weiter überlegen, wie ich die visuelle Handhabung mit Koda und die besonderen Ansprüche mit Child-GUIs unter einen Hut bekomme. Ideen sind willkommen!
Hmm...Du brauchst das also nicht für ein eigenes Projekt, sondern Du willst ein Programm erstellen, um visuell einen Settings-Dialog zu erstellen?
Nun, ich kann natürlich nur für mich sprechen, aber wer braucht sowas?
Ich gebe zu Bedenken, dass einer, der ein Programm erstellt, dass seitenweise Einstellungen erfordert und dementsprechend umfangreich ist, wohl nicht unbedingt ein Hilfsprogramm braucht, um die paar Zeilen Code für den Einstellungsdialog zu schreiben.
Vor allem, weil Du schon eine "eierlegende Wollmilchsau" schreiben müsstest, um sowas individuelles, wie einen Einstellungsdialog, für jedes erdenkliche Programm zu schreiben.
Ich habe in meiner gesamten AutoIt-Zeit nicht ein einziges Mal Koda zum erstellen einer GUI verwendet und ich denke, dass das bei sehr vielen so ist (wohl auch der Grund, warum das nicht mehr weiterentwickelt wird).
Und ein Programm zum erstellen eines Einstellungsdialogs halte ich für ähnlich überflüssig. Entschuldige, wenn ich Dir damit "auf die Füsse trete". Das ist nicht böse gemeint.
Ich wollte nur anregen, dass Du vielleicht mal eine Umfrage starten solltest, wer sowas gebrauchen kann, bevor Du allzuviel Arbeit da rein steckst.
Zitat von Professor BerndEinige Teile sind leicht zu färben, aber den großen Hauptbereich konnte ich bisher nicht färben. Hast du eine Idee, wie man das machen könnte?
Muss ich nachsehen, wenn ich zu Hause bin. Bei mir wird alles eingefärbt.
Off-Topic
Ich habe in meiner gesamten AutoIt-Zeit nicht ein einziges Mal Koda zum erstellen einer GUI verwendet und ich denke, dass das bei sehr vielen so ist (wohl auch der Grund, warum das nicht mehr weiterentwickelt wird).
Wohl auch der Grund, weshalb neue User für AutoIt meist Script-Kiddies sind, die Bots "programmieren" wollen. (siehe Off-Topic Spoiler).
Siehst du, da denke ich ganz anders. Ich denke, wenn es eine möglichst nahtlose Kombiantion von Text-Editor und visuellem Designer gibt, wird die Anzahl der Bot-Script-Kiddies "kleiner" werden. Das "kleiner" werden meine relativ zur Gesamt-Nutzerzahl! Natürlich werden es nicht wirklich weniger, sondern es werden einfach mehr Neueinsteiger animiert, AutoIt nicht nur für Bots und ähnliches unsichtbares Zeugs zu nutzen.
Wie wir alle wissen, war AutoIt ursprünglich zur Automation von Vorgängen gedacht, die unsichtbar im Hintergrund abliefen. AutoIt ist aber schon lange nicht mehr darauf beschränkt. AutoIt kann viel mehr, ist eine vollwertige Programmiersprache geworden (meine Meinung). Von den ernsthaft Interessierten zieht AutoIt nur die wirklich Willigen an, die es nicht scheuen, sich stundenlang dranzusetzen, um eine Oberfläche zu erstellen, die sie zur Entwicklungszeit nicht sehen können. - Außer denen zieht eine Programmiersprache für vorangig unsichtbare Anwendungen, mit denen man andere Anwendungen hervorragend manipulieren kann, natürlich die Script-Kiddies an. Und dass AutoIt vieles so Baby-einfach macht, tut auch sein übriges.
Ich selbst bin ein visueller Mensch (ist das richtig formuliert?). Damit meine ich, dass mich optische Reize mehr beeinflussen, als rein textuelle. Darum unterteile ich meine Texte auch in Abschnitte, benutze Satzzeichen und versuche Sätze zu bilden, die aus nicht mehr als 15 Wörtern bestehen! Dadurch wird das Geschriebene übersichtlicher, als wenn ich alles einfach aneinander klatschen würde. - Dementsprechend wäre ein WYSIWYG-Designer für GUIs ein mehr als willkommener Anreiz, AutoIt für mehr zu benutzen als für Bots.
Hmm...Du brauchst das also nicht für ein eigenes Projekt, sondern Du willst ein Programm erstellen, um visuell einen Settings-Dialog zu erstellen?
Doch es ist für ein eigenes Projekt. Es soll kein Programm werden, sondern eine Vorlage, die erstmal ein fertiges Grundgerüst bietet, dem mit wenig Aufwand komplette Settings-Seiten hinzugefügt werden können. - Das Ganze ist zum einen für mich, zum anderen soll es mit anderen geteilt werden. Viele mögen es, wenn man für Standard-Dinge wie einen About- oder einen Settings-Dialog nicht bei Null anfangen muss. ... Das ist die Idee. Und wie eingangs beschrieben, dass man die Vorlage einfach ändern und erweitern kann.
Entschuldige, wenn ich Dir damit "auf die Füsse trete". Das ist nicht böse gemeint.
Tust du nicht. Ich denke, wir alle "kennen" uns schon eine Weile, da sehe ich Kritik als etwas positives. Deshalb: Danke für deine Kritik! 
Muss ich nachsehen, wenn ich zu Hause bin. Bei mir wird alles eingefärbt.
Freu mich drauf!
Professor Bernd 's Offtopic: Ich stimme dir zu. Sobald es um Anwendungen mit ggf. Aufwändiger GUI geht, programmiere ich wenn möglich immer in Delphi (privat) bzw. Lazarus weil das wesentlich angenehmer und auch nicht getrennt ist (GUI-"Designer" und Programmieren in einem, ohne dafür alles per Hand in den Code schreiben zu müssen).
Sieht/sah bei mir genauso aus. Ich habe jahrelang begeistert in Delphi programmiert. Leider ist deren Geschäfts-Politik deutlich auf Gewinn ausgerichtet. Damit meine ich nicht, dass etwas verwerfliches an Gewinnstreben ist, sondern vielmehr geht es um die schlechte Art, wie Emba sein Kunden behandelt. Um den Schein zu wahren (Borland hatte immer wieder kostenlose IDEs) bietet Emba zwar eine kostenlose IDE an, aber man braucht eine persönliche Lizenz und die ist mit heftigen Hindernisse verbunden. Da fühle ich mich veralbert. - Da meine Lizenz vor ein paar Wochen ausgelaufen ist, habe ich Lazarus, CodeTyphon, SharpDevelop und MS Visual Basic in Augenschein genommen.
Es ist wirklich was anderes, wenn man mithilfe einer visuellen Oberfläche in ein paar Minuten eine Oberfläche erstellen kann, für die ich in AutoIt Stunden brauche! Andere sind da schneller.
Danke für deinen Beitrag!
[OT]
Das Thema wurde auch hier im Forum schon intensiv diskutiert.
Aber was ist denn Koda oder jeder andere visuelle GUI Designer, wenn man es auf die Funktion herunterbricht? - Ein "Tool" zur Erstellung und Beschreibung eines Layouts. Warum dann nicht VFL/DSL für AutoIt umsetzen?
Und man darf eines nicht außer Acht lassen: Es ist nur für Maus-Freaks gedacht. Ich bin ein Tastatur-Freak und vermeide Maus, wo es nur geht (meine Projekte für die Firma sind zu 100% ohne Maus bedienbar) . Und ich weiß, dass ich nicht der einzige bin, der so "tickt" 
.
[/OT]
@all Bitte entschuldigt, da kapere ich wohl meinen eigenen Thread. Deshalb der Hinweis, dass die eigentliche Sache soweit gediehen ist, dass ich einen eigenen Settings-Dialog erstelle. ... Vielleicht postet aber noch jemand einen Code, wenn er aus dem Urlaub zurück ist!? 
Bis dahin:
Warum dann nicht VFL/DSL für AutoIt umsetzen?
Was ist denn VFL/DSL?
Und man darf eines nicht außer Acht lassen: Es ist nur für Maus-Freaks gedacht. Ich bin ein Tastatur-Freak und vermeide Maus, wo es nur geht ... Und ich weiß, dass ich nicht der einzige bin, der so "tickt"
Wo habe ich das nur schonmal gehört!? ... Ach ja, die Linux-Anhänger hatten sowas gepredigt.
Auch wenn wir Maus-Freaks weit in der Überzahl sind, so darf es doch auch euch Randgruppen-Erscheinungen geben, die Paint, Photoshop/Gimp oder Koda mit der Tastatur bedienen wollen. Wir Maus-Freaks sind da tollerant! 
Bitte die Ironie-Smilies beachten.
Warum dann nicht VFL/DSL für AutoIt umsetzen?
BugFix - Das ging vielleicht im Off-Topic unter, aber ich würde schon gerne wissen, was mit VFL/DSL gemeint ist.
