Achso, tschuldige ,

schaut soweit ganz gut aus (dass die Elemente dynamisch "aussehen" und sich statisch verhalten, wurde ja bereits erwähnt) - Spinbutton und Textfeld funktionieren, was das Rendern in vorgefertigte Bilder betrifft: wenn du das Zeug nur für eine einzige Anwendung benötigst, bist du so wahrscheinlich schneller - auch wenn's mehr Speicher braucht.
Wenn du die Komponenten weiter verwenden möchtest, solltest du dir über eine skinbare Komponentensammlung Gedanken machen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Das ist bisjetzt nur ein Test für 1(!) Projekt was folgen soll... Aber wenn mal Zeit is werd ich mich vielleicht mal an eine solche Klasse wagen, die sowas dann automatisch macht...
Damit die Buttons dynamisch werden, wüsst ich jetzt net wie ich das machen soll...das müsste ja dann durch unmenegen Statusabfragen laufen oder??

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Am besten geht das wie bei der VCL. Jede Komponente bekommt eine Liste mit enthaltenen Komponenten. Dann gehtst du in einer Schleife die Liste durch, prüfts ob die Maus über der Komponenten war und rufts dann die entsprechende Methode dieser Komponente auf. Wenn jeder Button selber seinen Status speichert, dann muß jeder nur seinen eigenen Status setzen.
Wenn dann gezeichnet werden soll zeichnet jede Komponente sich erstmal selbst und dann wieder die untergeordneten. Dabei muß dann der Button nur seinen eigenen Status testen und dann entsprechend das eine oder andere Bild zeichnen. Es sollte auch möglich sein, die ganzen Objekte von TComponente abzuleiten. Dadurch könnte man sie sehr einfach auch aus .dfm Dateien laden. Vor dem Einlesen müssen dann noch die entsprechenden Klassnamen natürlich ersetzt werden. Also da sollte statt TButton dann TGLButton oder TGLForm oder wie deine Klassen heißen stehen.

Oh. Asche auf mein Haupt.


Danke freut mich zu hören. Was verstehst du denn unter "ganzes"? Momentan ist nur OnClick (Buttons, etc) und OnChange (Scrollbars) implementiert. OnMouseDown, OnMouseUp und OnMouseMove dürfte kein großes Problem sein. So etwas ähnliches benutze ich ja intern schon. Alles andere ist noch nicht implementiert. Edit könnte da auch noch sehr lustig werden, da ich ja keine Handels oder so etwas wie einen Fokus habe. Mal sehen wie ich das überhaupt machen kann. Die ListBox bekommt aber auf jeden Fall noch ein MeasureItem und DrawItem. Ganz wichtige Events.

Achja. Die MouseEreignisse müssen logischerweise vom Formular aus an die oberste Komponente gereicht werden.

@Lars: Das mit TComponent ist auch ne ziemlich witzige Möglichkeit. Allerdings ist die "Normale" TComponent so etwas wie ein ÖffnenDialog. Also ein kleines Unförmiges Ding. Damit kann man sehr schlecht (da nicht visuell) eine komplexe Menüstruktur zusammenbasteln. Und sobald man es visuell macht hat man das Problem, dass es sich um WindowsKomponenten handelt. Man müsste da schon einen Editor schreiben der so in etwa aufgebaut ist wie der von glScene. Aber der Aufwand für so etwas ist ziemlich groß.

@LossyEx
TComponent habe ich vorgeschlagen, weil die ganzen Streaming Funktionen darauf aufsetzen und man dann die dfm Dateien einfach einlesen kann. Die normalen Windows Komponenten kann man nicht nehmen. Selbst TControl geht vermutlich nicht. Aber man kann in der abgespeicherten .dfm Datei per Texteditor oder über StringReplace beim Laden die Klassennamen ersetzen. Also statt



sollte dann da



stehen, falls die eigenen Klasse TGLButton heißt. Die ganzen Funktionen die für das Streaming in classes.pas zuständig sind arbeiten nur mit TComponent und daher sollte das eigentlich kein Problem sein.

Mit Eventhandling meine ich, ob die Komponenten bei diversen Änderungen selbständig Ereignisse auslösen, auf die man dann reagieren kann und mit denen sie sich auch selbst anpassen können (etwa das automatische Verschieben einer Listbox, wenn die zugehörige ScrollBar verschoben wird und umgekehrt) - aber in dem Fall kann man wirklich schön Ereignisse zuordnen, dass es zur Zeit noch nicht so viele sind, ist ja prinzipiell nicht so wichtig .

An sich wären allerdings TabOrder und Fokus schon angenehm, insbesondere wenn man das Ganze auch per Tastatur durchnavigieren können soll (wobei ich mich jetzt nicht in dein Menüsystem einmischen will - kommt ja auch ganz drauf an, wofür du es brauchst).

Ich denke für eine eigene visuelle Umgebung könnte man sich auch recht gut an der Philosophie Borlands Turbo Vision orientieren - über verkettete Funktionsaufrufe, konnta man quasi mit einer Befehlszeile ein ganzes Menü aufbauen - am Anfang etwas gewöhnungsbedürftig, aber sehr gut durchdacht und funktional.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@Mars: Jain. Die Listbox und die dazugehörige Scrollbar sind eigentlich eins. Aber auf dem Bild wird der selektierte Listboxeintrag mittels der Scrollbar daneben ausgewählt (klicken funktioniert noch nicht). Und mittels dem "Blub" Button lassen sich "Krönk"Einträge erstellen die als Nummer die Anzahl der Listboxitems benutzt. Also um deine Frage mal ein wenig zu klären.
Allerdings befürchte ich auch, dass ich früher oder später um einen Fokus nicht herum kommen werde. *schnief*

@Lars: Ich glaube jetzt habe ich genau verstanden was du vor hast. Das könnte in der Tat funktionieren. Wenn man gleichzeitig noch die Deklaration in der pas ändert. Allerdings muss man dann peinlich genau drauf achten auf welche properties man zugreift. Da stellt sich mit allerdings die Frage ob das den Aufwand rechtfertig? Und ob man vom jedem (auch Anfänger) verlangen kann in der DFM rumzuschreiben?

Wobei ein größeres Problem allerdings auch die Texturkoordinaten sein dürften. Fällt mir gerade auf. Bei meinen Kompos hat ja alles mindestens eine Texturkoordinate und irgendwelche Randefinitionen. Zwecks Flexibilität.

Mit zusätzlichen Properties ist das natürlich schwierig die dann irgendwo noch unterzubringen. Fehlende Properties sind für das Streaming System kein Problem. Man kann ja auch *.dfm Dateien in älteren Delphi Versionen einlesen, bei denen es bestimmte Properties noch nicht gab. Das Ersetzen der Komponentenklassen würde man optimalerweise beim Einlesen der dfm Datei machen. Mit TComponent hat man eine gewisse Grundlage und das dfm Format ist ja an sich für alle Objekte tauglich die von TComponent abstammen und die müssen ja keinen Bezug zur restlichen VCL haben. Wenn man seine Klassen da irgendwie elegant auf TComponent aufsetzen kann, dann bekommt man den Editor und das Dateiformat mit Laden und Speichern umsonst dabei. Außerdem hat man dann auch gleich die ganzen TPersistent Objekte wie TStrings usw.. und die Collections mit dabei.
Das dfm Textformat ist eigentlich auch als Menü Defintion in Spielen tauglich. Ich habe es selber noch nicht ausprobiert werd das aber mal machen. Es muß sich allerdings, da stimme ich dir zu, von Arbeitsaufwand im Gegensatz zur spezielleren Lösung lohnen. Wenn es dabei bleibt dass man nur die Klassennamen ersetzen muß, dann hält sich das ja in Grenzen.

Öhmm...anscheinend habt ihr schon sowas wie ne glMenue gebastelt?? Könntet ihr die ne Frei zugänglich machen... Weil wenn es sowas gäbe (einfach in die Uses Liste. Klasse Auswählen, postieren, Texturen zuweisen, Zeichnen lassen) dann wär das ja enorm praktisch und mann müsste net alles selber bauen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich hab für ein Projekt mal ne komplette OpenGL-GUI Unit gemacht die auch in Sachen Ereignisbehandlung einigs mitbringt und die GUI aus XML-Dateien lädt. Allerdings sollte man sowas selbst machen, oder nur dann verwenden wenn die fremde Unit auch nen eigenen GUI-Editor mitbringt. Wenn ich meine Unit so veröffentlichen würde, dann müsst ich bestimmt permanent irgendwelche Anfragen beantworten, weshalb ich das lasse.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also neben ner Redbook übersetzung is das jetzt das nächste was man durchaus gebrauchen könnte und noch nicht existiert (öffentlich).

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nun mal nicht drängeln.
Auf Sulaco gibt eine Unit mit der kann man bereits Fenster und Elemente erstellen. Das ganze schimpft sich glWindows und ist für meinen Geschmack ein wenig zu unflexibel und kann zu wenig. Abgesehen davon, dass OOP für diese Unit ein Fremdwort ist. Allerdings ist es für die Komplexibilität deines (und das von vielen anderen) Menüs vollkommen ausreichend. Auf langer Sicht wahrscheinlich nicht aber für den Anfang doch schon ziemlich gut. Erweitern kann man das ja dann schließlich auch noch.

Und ich bastel ja auch an etwas. Ich würde es ja auch nicht so publizieren wenn ich es nicht veröffentlichen wollte. Nur momentan wirst du daran noch nicht wirklich viel spaß haben, da der MenüEditor noch nichts wirklich brauchbares raushaut und eine Dokumentation auch noch nicht existiert. Na ja. Ein Bild von den Rects bei der Scrollbar. Weil das so viele sind. Sonst würde ich die selber fast vergessen.

Aber für den Fall, dass sich genügend Stimmen melden könnte ich die bisherige Unit schon einmal publizieren. Ist zwar noch tiefstes Entwicklumsstadium aber an so Sachen wie Panel, Button, Check-, RadioBox und Image ändert sich halt auch nicht mehr so viel. Hoffe ich jedenfalls.

Wenn deine Klasse so angelegt ist, dass man eigene Texturen Laden kann um die Optik zu verändern dann drängel ich dich aber... XD

Wie gesagt, arbeite ich mit einigen anderen (u.a. auch hier bei DGL verteten) an nem größeren Projekt. Im Moment ist es kein Problem ein Testmenü über Texturen zu basteln. Aber wenn du da ne Componentensammlung hättest mit echten OnClick Sach etc. dann wär das schon ziemlich doll (gesetzt dem Fall wir dürften die überhaupt verwenden 8) )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nö dürft ihr nicht.
Natürlich dürft ihr die dann verwenden. Was eine Frage...

Zum Thema eigene Texturen bzw. Skinfähigkeit verweise ich mal nur auf den Anhang! Das dürfte ja hoffentlich alles erklären.

Die unter Elemente benutzen die selbe Textur wie Oben. Also auch die selben Ausschnitte. Da wurde aber nur eine Farbe gesetzt. CheckBox, RadioBox und Scrollbar kann ich so nicht zeigen, da die im Editor noch nicht implementiert sind. Ich muss mal sehen ob ich es heute noch schaffe die Qualen hoch zu laden. Andernfalls wird es Freitag.

PS: Die Elemente verwenden meine Textur und Fontklasse. Auch erhältlich aus dem DGL-SDK. Allerdings hat sich da an der Fontklasse zu viel geändert. Also wurde massiv erweitert.

wenn du den ordner nicht löschen konntest hat sich die exe wahrscheinlich beim schließen der anwendung aufgehangen und du hast es nicht gemerkt. bei ntfs (oder generell windows 2000+, keine ahnung) musst du sogar alle dateien geschlossen haben damit du die überhaupt löschen kannst.

_________________
www.omfg.biz - aktuelles projekt