Meine Lieben,
ich gehe jetzt schlafen und verabschiede mich.
Traude

Nein, das ist ein allgemeines Message System,aber in der VCL wird es für Windows Nachrichten benutzt. Der übergebene Record ist egal, der Parameter ist ja auch ohne Type deklariert. Wichtig ist nur der erste Integer in dem Record, denn daraus erkennt Dispatch die Nummer der Nachricht. Es wird diejenige Methode die mit "message ID;" deklariert wurde aufgerufen, oder falls sie nicht gefunden wurde dann der DefaultHandler. Man kann das also für beliebige eigene Nachrichten benutzen. Die beiden Funktionen sind auch virtuell und können daher für eigene Klassen überschrieben werden.

Meine Kritikpunkte sollten eigentlich nur eins aufzeigen.
Es passiert schon wieder das gleiche, es entsteht Papierkorb arbeit.
Es ist völliger verschwendete Zeit prototyping zu machen, wenn man nicht weiß was überhaupt gefordert ist.

Ich werde morgen mal ein bischen was ausarbeiten, damit das Projekt wieder in geregelten Bahnen weiter laufen kann.
Der Anfang hat doch schon sehr gut funktioniert gehabt .

Wir wollen hier einen Standard für Pascal GUI schaffen und das erfordert Geduld und eine wohl durchdachte Planung.
Ohne Ziel sich auf etwas zu stürzen bringt in der Regel nichts hervor und wenn dann auch nur murks.
Unser Ziel ist doch ein Qualitativ hochwertiges System zu entwickeln, welches auch gerne genutzt werden soll.

(... und nein ich fühl mich nicht beleidigt, auf den Schlips getreten oder ähnliches.
Ich möchte nur versuchen die von euch und mir verwendete Zeit nicht nutzlos zu vergolden.)

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

@Tak: Vielleicht fühle ICH mich aber auf den Schlips getreten?!

Angenommen, Du liest irgendeinen Code von einem Dir nicht näher bekannten Programmierer. Dann gehst Du zu ihm und sagst ihm, seine Arbeit sei "böser Code" oder "Murks" oder "Papierkorbarbeit", dann ist das schlecht, weil ......

1) das Ärger und Magenschmerzen beim Programmierer verursacht und
2) das möglicherweise gar nicht stimmt, weil das keine sachlichen Argumente sind, die irgendwas beweisen.

Außerdem könnte der Programmierer die Lust an dem Ganzen verlieren. Mein Beitrag ist als Dankeschön für die Community gedacht, weil sie mir wirklich viel gebracht hat. Ich brauche kein Portfolio oder Referenzen oder so etwas. Und was würdest Du dazu sagen, wenn ich das mit Dir mache? Ich sehe mir Deinen Code nur flüchtig an, behaupte, das sei Murks und überhaupt kann ich das viel besser? Scheint mir keine gute Grundlage für eine Zusammenarbeit zu sein. Wer wird sich noch trauen, hier etwas zu posten, wenn er damit rechnen muss, dass man ihm sagt, seine Arbeit sei ein "Murks"? (Der Murks läuft in dem halb fertigen Programm mit 3D, das ich schon erstellt hatte, ganz ordentlich ). Also bitte, ich ersuche um ein bisschen mehr Sachlichkeit bei der Kritik.


Und noch etwas: Wir haben Vorgaben erarbeitet. Ich habe mich die ganze Zeit bemüht, alle Vorschläge in den Text einzuarbeiten. Im Laufe der Diskussion ist es sehr praktisch, immer den aktuellen Text zu haben, auf den sich alle einigen konnten. Diese Vorgaben waren dazu gedacht, eine Rahmen für die Programmierung zu erstellen, also die Anforderungen darzustellen (das, was gebraucht wird, wie Du gesagt hast). Nach Abschluss der Vorgaben ist es der nächste logische Schritt, mal ein Grundelement zu erstellen. Über das Grundelement diskutieren wir gerade. So sehe ICH das.



@Lars: wieder ein Auszug aus der Delphi-Hilfe, betrifft TObject.Dispatch:



Schaut eigentlich aus, als obs genau auf unseren Anwendungsfall passt. Ich habe das allerdings noch nie gemacht, die Dispatch-Methode überschrieben. Der Record müsste dann noch angepasst werden, aber es steht ja, dass das sogar so vorgesehen ist.
Traude

Ich hab den Thread eröffnet, gerade weil ich weiß das mein Code nicht gut ist.
Denn ich weiß wie der Code entstanden ist(mit wenig vorbereitung und einer menge Prototyping).

Ich hätte wahrscheinlich am anfang mal eine von mir gedachte Schrittliste mit reinwerfen sollen.
1)Brainstorming->Lastenheft
2)Analyse von schon existierender Software, wie z.B. VCL, GTK,...
3)Pflichtenheft
4)Aufbau der Software(Softwarearchitektur in Diagrammen festhalten)
5)Programmierung

Jetzt erzähliche ich noch ein bischen dazu.
Das Lastenheft ist wichtig, da ohne dieses man garnicht weißt was so alles realisiert werden kann.
Unser Brainstorming war schon sehr weit und Traudes Dokument kommt auch schon nahe an das Lastenheft ran.

Die analyse von anderen schon existierenden Produkten kann einiges zeigen.
Wer z.B. vermehrt die VCL von Delphi nutzt, weiß in der Regel wo man selber Probleme hat und was sehr praktisch ist.
Dieses kann man dann aufgreifen und verbessern oder übernehmen.
Ausserdem fallen dann noch dinge auf, an die man garnicht gedacht hat.

Pflichtenheft filtert allen nicht notwendigen Teil aus und geht detailierter als das Lastenheft vor.
Was im Pflichtenheft enthalten ist, ist das was am ende raus kommt.

Spätestens hier, wenn man visuell sieht wie die Module miteinander verknüpft sind und Klassen mit einander aggieren, findet man noch fehler oder missstände im Pflichtenheft.

Die programmierung ist klar, man übernimmt alles aus den Diagrammen und fügt noch Code in die angegebenen Funktionen.
Ist der leichteste Teil, da in den Diagrammen ja alle Klassen mit ihren Variablen, methoden und so weiter angegeben sind.


Nun könnt ihr auch sagen, dass ist mir zuviel Arbeit und ich will mit den Coden weiter machen.
Mit der entscheidung habe ich auch kein Problem und werde sie hinnehmen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Dann nochmal zur GUIUnit.pas:
Über das Ereignisstruktur kann man später nochmal diskutieren, es fehlen aber zumindest Differenzierung zwischen Pressed und Released. Auch kann man nicht zwischen linker und rechter Maustaste differenzieren, die meisten Mäuse haben noch mehr Tasten die so verloren gehen, wobei die Differenzierung ja nur in TGUIEvent erfolgt ist.

Dann zu TGUIItem:
Es fehlen TGUIItem.Left und Top für die Positionierung der Objekte. fFocusedChild gehört in den GUIManager und nicht in GUIItem, einfach weil es eh nur ein fokusiertes Objekt gibt.
Zu fGUIItem bin ich noch immer der Ansicht, dass es eine Liste sein sollte. Einfach weil späteres Umstellen grössere Probleme erzeugen könnte und vorallem sollten wir an dieser Stelle nie gezwungen sein zu debuggen, weil wir dann einen Konzeptfehler haben.
Unter Propertys fehlt noch Parent, damit man z.b. ein Button von einer Form in ein Panel verschieben kann.

Zu AddGUIItem:

Ansich sollte man dann aber machen:
MyButton := TGUIButton.Create('MyButton', Parent);
Denoch braucht man sowas ähnliches wie AddGUIItem, wenn sich ein Kind bei seinem Parent registrieren will.
An der Stelle gibt es zwei Möglichkeiten:

1. Es existieren (public) Funktionen wie AddGUIItem und RemoveGUIItem die ein Child aufruft.
2. fGUIItem ist public und das Child trägt sich dann selber ein und aus.

Die beiden Möglichkeiten nehmen sich nichts, beim einen Fall steht der Code beim Free und Create, beim anderen in Extrafunktionen.

Dann ist mir ebengerade noch die fItem*-Elemente aufgefallen:
Wäre es nicht sinnvoller hier direkt die entsprechenden Funktionen/Proceduren hinzuschreiben als Variablen von Funktionen/Proceduren?
Bei den fUser*-Elementen macht es so Sinn, bei fItem* sehe ich aktuell keinen.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Hallo Tak,
Ich wollte Dir bloß zeigen, dass ich mich nach Deinem Post richtig mies gefühlt habe. Nicht mehr, aber auch nicht weniger.

Warum ich die XD-GUI nicht als Vorlage nutzen will, ist leicht erklärt: es besteht hier die Möglichkeit, unter den Augen der Community ein neues Konzept zu erstellen, bei dem alle etwas einbringen können, die sich dazu berufen fühlen. Wenn wir/ich einen Fehler machen, könnte die Community uns berichtigen, und mir scheint, das hat sie bereits getan. Danke, Lars.

Und ja, es ist Dein Thread. Du bist hier der Projektleiter. Ich habe mir nur den Posten als Schriftführer unter den Nagel gerissen (man kann als Projektleiter viel lernen, z.B. den Umgang mit widerspenstigen alten Damen).

Was Du da gesagt hast, wie Du das machen möchtest, das finde ich richtig gut. Ich möchte weitermachen und warte mal, was Du jetzt haben willst.

Ach übrigens: ich war gerade in meiner Lieblings-Buchhandlung und habe ein Buch über Lua entdeckt. Es liegt jetzt neben mir am Schreibtisch.
Traude

Hehe, naja mit I0n0s und Frase arbeite ich über irc, da ist das ganz anders als im forum ^^.
Ich wollte auch niemanden beleidigen.

Lua ist was ganz feines hat viele Vorteile und hat sich in der Gamebranche am weitesten etabliert.
Durch das Tabellenkonzept(alles liegt in Tabellen) ist es auch die beste Scriptsprache, so meine Meinung.
Im Buch wird das wohl ziemlich am Anfang noch kommen mit Vorteilen und Nachteilen.

Ich denke ein übersichtliches Lastenheft könnte her.
Wenn das fertig ist können wir uns mal mit schon existierenden GUIs beschäftigen.
Vieleicht gibs ja noch dinge die wir garnicht beachtet haben oder nicht detailiert genug ausgearbeitet haben(soviel verrate ich: es ist definitiv der Fall ^^ ).
In der Regel sind es die Dinge, die wir für selbst verständlich halten.

Ich bin erstmal bis heut abend away.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich habe das Ganze sehr gespannt verfolgt und ich bin der Meinung dass ich jetzt auch mal meinen Senf dazu geben sollte. Der Ein oder Andere wird es noch wissen. Ich bin auch seit geraumer Zeit daran eine GUI zu schreiben. Und dies ist bereits mein zweiter Versuch.

Ohne jetzt irgendwas zum Projekt zu sagen. Ich denke ihr seit schon ein kleines bisschen zu weit. Ihr redet schon über Details wie die Messages weiter gegeben werden etc und alles. Aber ich denke ihr habt noch nicht das Wichtigste geklärt. Und zwar wie die internen Strukturen aussehen bzw wie sie miteinander zusammen arbeiten sollen. Was wollt ihr alles mit der GUI anstellen? Was soll die GUI an sich alles können? All diese Fragen wurden noch nicht angesprochen. Aber genau diese Sachen sind es die den internen Aufbau der GUI zu 90% bestimmen.

Solche Sachen wie es muss ein fallback Renderer zur Verfügung gestellt werden sind zwar ganz nett aber wenn ihr ganz ehrlich seid und genau drüber nachdenkt wisst ihr, dass das nur eine nette Spielerrei für außen rum ist! Zur Wirklichen Funktionalität einer GUI würde ich das nicht mit dazu rechnen. Genau so die Unterstützung für LUA. Klar ist es vorteilhaft und sogar nötig so etwas von Begin an in seine Überlegungen mit einzubeziehen. Vor allem aber solltet ihr auch überlegen was alles für die GUI dann notwendig sein wird. Wenn ihr als beispiel LUA vorschreiben würdet wären einige sicherlich nicht davon angetan.

Bevor jetzt die Frage aufkommt warum ich mich dem Projekt nicht anschließe sondern eher weiter an meinem Projekt arbeite. Das liegt daran, dass ich grundsätzlich ganz andere Anforderungen an meine GUI stelle und funktional auch andere Bereiche bedienen möchte. Bzw durch meine langjährige Arbeit mit der Windowsoberfläche und durch den ersten gescheiterten Versuch habe ich mir mittlerweile eine Struktur für meine Objekte erdacht und gebaut von der ich nur mit wirklich sehr guten Argumenten abweichen werde. Und ich habe mir das alles sehr genau überlegt.

Hallo, Lossy eX,
das freut mich ganz besonders, dass Du vorbeischaust.

Naja, Tak hat ja auch jetzt die Losung ausgegeben, dass wir uns jetzt eigentlich ums Konzept kümmern müssten, so wie Du das auch meinst. Wir diskutieren solche Dinge wie Messages und Skriptsprache, gerade weil wir uns jetzt um die Grundstruktur kümmern wollen und man beim Konzept erstellen einen Blick in die Zukunft werfen muss damit die Daten-Struktur die Dinge, die man sich wünscht, auch wirklich bewältigen kann.

Und da ich natürlich weiß, dass Du auch eine GUI bastelst, habe ich gehofft, dass Du Dich mal meldest. Weil ich natürlich auch weiß, dass Du schon eine gemacht hast. Und daher schon Erfahrung hast.

Daher hätte ich - vorbehaltlich, dessen, was Tak meint, weil er ist offensichtlich gerade nicht da - eine Bitte an Dich. Du hast schon Erfahrung im Erstellen einer GUI. Könntest Du bitte ein Auge auf uns haben? Ich will Dich nicht belasten, Du hast ja offensichtlich genug am Hals. Aber es würde uns ja schon helfen, wenn Du bemerkst, dass wir Deiner Meinung nach in die falsche Richtung koffern (zu deutsch: laufen), dass Du einen kurzen Hinweis gibst. Das würde bereits reichen. Die GUI soll ja auch der Community zugute kommen.

@Edit: Ich bitte um Verständnis, dass ich zu Deinen Anmerkungen nichts sagen kann. Wenn ich das täte, würde ich es machen wie die Politiker, der eine sagt A, der andere sagt B. Wir müssen uns darüber noch einigen, wenn wir uns einig sind, können wir auch etwas dazu sagen.

Traude

Hallo, ihr alle! (Achtung, ein Monster-Beitrag)
Ich habe ein ganz seltsames Hirnkastl. Wenn ich abends noch ein Problem wälze, und zu müde bin, es zu lösen, dann arbeitet es in der Nacht weiter, ganz ohne mein Zutun. Wenn ich morgens aufwache, weiß ich die Lösung. Ich sollte mir das patentieren lassen.

Heute morgen ist mir auf diese Art ganz klar geworden, warum ich mit Euch jüngst Probleme hatte. Schuld ist es meine eigene. Ich hatte das TGUI-Element nur als Vorstellung eines Konzepts gedacht, nicht als fertigen Code (es ist Euch ja auch aufgefallen, dass Variablen und Methoden fehlen). Weil man in das Schreiben von Pascalcode so leicht hineinfallen kann (man sollte direkt ein elftes Gebot aufstellen: Du sollst nicht zu früh Code veröffentlichen), konnte ich der Versuchung nicht widerstehen und habe das Konzept als Code hier hineingestellt.

Und, was die eigentliche Ursache von dem ganzen Fiasko war: Ich habe das nicht lauthals dazugesagt, dass es eben nur ein Konzept ist.

Die Folgen davon habt Ihr hier gesehen: die Leuten haben es falsch verstanden und ich habe mich emotionalisieren lassen weil ich wiederum nicht verstanden habe, warum sie sich so aufregen. DAS WAR EIN SCHWERER FEHLER. Aber ich bin schließlich auch nur ein Mensch. Wie heißt es so schön: The ultimate winner is always capable to change any disadvantage into an advantage(frei nach Spiderman). Und daher sage ich jetzt mal: Ihr habt hier eine schöne Demo, wie man es nicht machen sollte.

Übrigens, zum Thema "change disadvantage into advantage" kennt ihr diesen uralten Witz (ist noch aus der Zeit des "kalten Krieges"): Berater zum amerikanischen Präsidenten: "Herr Päsident, was sollten wir machen, die Russen sind zum Mond geflogen und haben ihn rot angemalt?" Antwort: "Kein Problem. Fliegt ihnen nach, nehmt weiße Farbe mit und schreibt >>Coca Cola<< drauf."

-----------------------------------------------------------------------------------------------

Ich werde es jetzt anders versuchen: ich erzähle Euch einfach, wie ich mir vorstelle, dass ein GUI-System funktionieren soll, und bitte nehmt es als Konzept bzw. als Diskussionsgrundlage.
Ich hoffe, dass ich damit auch I0n0s Fragen beantworten kann (siehe sein letzter Beitrag weiter oben).
zur Erinnerung: wir befinden uns hier in Taks Phase "Lastenheft", dh. Grobkonzept erstellen.

VORSCHLAG: Baumstruktur
Die GUI kann als n-wertiger doppelt verketteter Baum implementiert werden, "n" ist hier die Anzahl der möglichen Unter-Knoten, die ein Baum-Knoten haben kann, wobei für "n" hier jede ganze Zahl im Bereich von [0] bis z.B. [High(Integer)] eingesetzt werden kann. Von "n" verlange ich größtmögliche Flexibilität. Damit kann man jeden Baum bauen, von einem Baum, der nur aus der Wurzel(Root) besteht oder einem kleinen "Setzling" bis zu einer Eiche.
Doppelte Verkettung bedeutet: jeder Knoten des Baums soll schnellen Zugriff auf seinen Vaterknoten(Parent) als auch auf seine Kindknoten(Children) haben.

Ein Node, der kein Parent hat, ist die Wurzel des Baums(Root), wenn keine Children existieren, ist es ein Blatt(Leaf). Es gibt nur ein Root, Leafs kann es viele geben.

Vorteile:
Baumstrukturen sind für ihre Schnelligkeit bekannt
Man kann mit einer Baumstruktur ganz leicht den "Dienstweg" einhalten, weil er einen so schönen hierarchischen Aufbau hat. Es ist ungeheuer leicht, sowohl die ganze Hierarche abzuklappern als auch nur einen bestimmten Zweig davon

Nachteile: sehe ich keine

VORSCHLAG: Alle Knoten(Nodes) in diesem Baum leiten sich, wie in unseren Vorgaben vorgesehen, von einem Grundelement ab, auch das Root-Element, das auch als GUI-Manager fungiert.

Vorteile:
Dieser Aufbau unterstützt die Kommunikation zwischen den Nodes. Unter "Kommunikation" verstehe ich hier nicht nur die Weiterleitung von Information, sondern auch das Aufrufen von Methoden untergeordeter Nodes(Children) oder übergeordneter Nodes(Parent)

Ein Beispiel: Das RootNode wird aufgefordert, die GUI "wegzuschalten" (unsichtbar zu machen, inaktiv zu machen. wie auch immer Ihr das sehen wollt). Das Root könnte darauf hin die Prozedur TreeSetActive(False) aufrufen, welche beim Root alle Nodes inaktiv setzt. Diese Funktion setzt aber eine Kettenreaktion in Gang, weil jeder Node wieder seine eigene Methode TreeSetActive aufruft, bis zu letzten untersten Knopf. Allerdings müssen nicht alle Funktionen des Basis-Elements TREE-Funktionen sein. Eine Methode "SetVisible" oder "Draw" wären Beispiele für solche TREE-Funktionen.


FRAGE: Was sollen das Basiselement leisten können?
Vorschläge:
1) Es soll fähig seine, seine Nodes selbständig zu erzeugen und freizugeben.
2) Es soll fähig sein, sowohl mit seinem Parent als auch mit seinen Nodes Daten auszutauschen
3) Es soll fähig sein, Methoden sowohl seines Parents als auch seiner Children aufzurufen. (Das bedeutet in meinem Konzept, dass im Basiselement alle Tree-Funktionen. implementiert werden müssen).
4) Es soll grundlegende Methoden definieren (aber noch nicht implementieren), die für eine bestimmte Funktion die zuständige Methode definieren ( z.B. Draw,LoadFromFile,...), die dadurch von den Tree-Funktionen bereits im Basiselement benutzt werden können. Die wirkliche Implementierung dieser Funktionen erfolgt erst in den abgeleiteten speziellen GUI-Elementen.

Es läuft darauf hinaus, dass Folgendes möglich sein soll (nochmal zur Vedeutlichung):
Der GUI-Manager wird angewiesen: Draw! Der Manager ist ein lediglicher Verwalter und braucht deshalb keine Draw-Funktion. Aber er hat dafür zu sorgen, dass jedes seiner (individuellen) GUI-Elemente sich auf seine ganz spezifische Art zeichnet, und zwar nicht nur seine Elemente (Nodes), sondern auch deren Elemente usw., wie gesagt, vom größten Fenster bis zum letzten untersten Knopf. Noch Deutlicher: JEDER Knoten, auch der GUI-Manager, ist nur für seine eigenen Children verantwortlich. Und er kann nur diese "anregen", etwas zu tun. Alles weitere überläßt er der Hierarchie.

Hier möchte ich jetzt mal Schluss machen.

Traude

So, mein Kommentar zu den Monsterbeitrag:

Zur Baumstruktur:
Entweder ist die Wurzel der GUIManager oder es darf mehr als eine Wurzel geben.
Ansonsten kann man nicht mehrere Fenster haben.
Die Baumstruktur klingt aber gut, auch das mit der doppelten verketteten Liste.


Ich muss hier wieder den GUI-Manager rausnehmen. Ein GUI-Manager benötigt z.B. keine Positionierung im Raum oder einen Namen. Der GUI-Manager sollte eine eigene Struktur haben (einfach weil er so speziell ist). Alle anderen GUI-Komponenten werden von einem Grundelement abgeleitet.



Nein, ein Node sollte sich selbstständig erzeugen. Die Freigabe kann entweder über den Node selber als auch in seinem Parent erfolgen (Rekursive Freigabe soll halt möglich sein).


Könntest du das mir nochmal erklären? Verstehe ich gerade nicht


Also im Prinzip sage ich als Developer:
GUI-Manager.Draw
Der GUI-Manager sagt dann für alle sein Kinder: Child[i].Draw
Ein Kind sagt dann zu seinen Kinder: Child[i].Draw und so weiter. Sodass bei allen Elementen aus dem Baum die Methode Draw aufgerufen wird.
Das klingt sehr vernünftig und sollte auch bei den Events etc. implimentiert werden.

Dann zu deinem "Hirnkastl":
Patentieren fände ich doof, stell es unter OpenSource und erlaube es es auch zu benutzen

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Anstelle des GUI Managers kann man auch ein spezielles Desktop Fenster nehmen, dass die verfügbare Fläche einnimmt und bei Bedarf transparent sein kann.

I0n0s schrieb:


Gemeint war: der GUI-Manager ist das Root. Das erklärt auch, warum alle meine Elemente ein FFocusedChild haben. Man hat damit die Möglichkeit, per Baumstruktur blitzschnell das fokussierte Element zu finden, auch wenn man den Bildschirm mit vielen GUI-Elementen vollgestopft hat. Und ich glaube, das war noch eine Anmerkung von Dir: es kann nur EIN fokussiertes Element geben. Das ist nicht ganz so: Du hast z.B. ein Fenster mit vier Panels. In jedem Panel gibts diverse Buttons etc. Dann läuft die ganze Sache so: der GUI-Manager schaut welches seiner Fenster den Focus hat. Nun, er hat nur eins (könnten ja auch mehrere sein). Dieses Fenster hat vier Panels. Panel Nr.3 hat den Focus. In diesem Panel hat Button Nr. 6 den Fokus. Hätte der Node sich sein fokussiertes Element nicht gemerkt, müsste er sie alle durchsuchen. Das dauert länger. Verstehst Du, er läuft den Baum hinunter, auf der kürzest möglichen Strecke, mit der schnellstmöglichen Methode. Das habe ich oben als "Dienstweg" bezeichnet. Ich glaube, man begibt sich in Teufels Küche, wenn man diesen Dienstweg verlässt.

I0n0s schrieb:


Ich habe bei meinem ersten Projekt den GUI-Manager auch vom Grundelement abgeleitet. Und zwar einfach aus Faulheit: es war so, dass der GUI-Manager viele Gemeinsamkeiten mit dem Basiselement hatte. Das Basiselement hatte zwar ein paar Dinge, die der GUI-Manager nicht braucht und vice versa. Aber es war keine wirklich große Speicherverschwendung. Und ich hätte den Code für die TREE-Funktionen in den GUI-Manager hineinkopieren müssen, hier braucht er wirklich den gleichen Code. Das hab ich mir erspart. Und ich bitte zu bedenken, dass, wenn immer eine neue TREE-Funktion implementiert wird, man einen GUI-Manager, der nicht vom Basis-Element abgeleitet ist, AUCH auf den neuesten Stand bringen muss.



Das verstehe ich jetzt nicht. Wie erzeugt sich ein TObject selbst?
@Nachtrag: In dem pas-Feile, in dem das TGUIItem enthalten ist, gibts eine interessante Destroy-Methode: TGUIItem.Destroy. Diese Methode macht genau das, ist aber nicht rekursiv, sondern eine TREE-Methode.

I0n0s schrieb:

[die Frage bezog sich auf den VORSCHLAG, Punkt4]
Ein Beispiel: Du leitest eine TXYZObject von TObject ab und gibst ihm eine Methode LoadFromFile, die völlig leer ist und ausserdem als "virtual" gekennzeichnet sein muss. Es ist vorgesehen, dass Du aus diesem TXYZObject andere Objekte ableiten möchtest, etwa TXYZButton, TXYZLabel. Die beiden können jetzt ihre eigene Methode LoadFromFile implementieren. Diese Methoden müssen mit "override"gekennzeichnet sein. Das bedeutet, dass TXYZButton die ursprüngliche Methode TXYZObject.LoadFromFile ÜBERSCHREIBT. Mit dieser etwas umständlichen Art ist zunächst einmal nur gewährleistet, dass alle abgeleiteten Objekte die Nomenklatur wahren müssen (ich sehe das als eine Art Richtlinie). Ich habe hier für diese Art Methoden zu definieren allerdings noch einen sehr wichtigen Grund: meine Tree-Methoden. Diese sind im Basiselement zu definieren, und NUR DORT. Die Tree Methode verwendet die Methode LoadfromFile, deswegen ist es zwingend, diese Methode im Basiselement zu definieren, obwohl sie überhaupt keinen Inhalt hat.

Beim TXYZButten funktioniert das so: Die Methode TXYZButton.TREELoad ist identisch mit der Methode TXYZObject.TREELoad. Wegen der Vererbung verwendet aber TXYZButton.TREELoad die Methode TXYZButton.LoadFromFile, die im Unterschied zu TXYZObject.LoadfromFile auch eine sinnvollen Inhalt hat.

Was ermöglicht mir das? Ich kann einen Baum mit völlig verschiedenen Elementen haben und sie können alle friedlich nebeneinander koexistieren und Methoden verwenden, die zwar ganz gleich heißen, und vordergründig auch das gleiche tun, ABER SIE HABEN EINEN GANZ VERSCHIEDENEN INHALT: Ein Button muss eben einen anderen Code in seiner Lade/Zeichnen/Irgendwastun-Methode haben, als ein ScrollItem. Und alle diese Dinge werden mit den TREE-Funktionen aufgerufen, die sich nur im Basisobjekt finden. Es grenzt irgendwie an Zauberei.

I0n0s schrieb:


Ja genau.


I0n0s schrieb:


Das könnte Euch so passen.




@Lars: Mit dem GUIManager kann man machen was man will. Man könnte ihn auch als Fenster implementieren. Das ist Geschmackssache. Ich habe ihn in meinem ersten Projekt dazu benutzt, dem Programmierer das Initialisieren von SDL und OpenGl abzunehmen. Er hat sozusagen auch Applikationsfunktionen übernommen und hat selbst die SDL-Ereignisse abgefangen. Der Phantasie sind hier keine Grenzen gesetzt.

Traude

Mir ist übrigens heute Nacht während der Versuche einzuschlafen eingefallen was mich an dem FocusedChild so stört:
Wir haben noch an einer Stelle 2 Konzeptmöglichkeiten:

1. Falls ein Event nicht auf ein Element zutrifft wird es nicht an die Kinder weitergegeben
2. Falls es auf ein Element nicht zutrifft wird es denoch weitergegeben.

a) hat den Vorteil, dass bei Events nicht immer der ganze Baum durchlaufen wird. Dafür müssten alle Childs in dem Bereich des Parents liegen. (Würde ich wegen glScissor empfehlen, ist aber eine Einschränkung bei der wir überlegen müssten ob wir sie haben wollen.)
b) sorgt dafür, dass alle Elemente von den Events mitbekommen und so reagieren können (OnHover etc.) Desweiteren können die Kinder unabhängig von ihren Eltern im "Raum" liegen.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄