Sidorion schrieb:



Die Diskussion scheint darauf hinauszulaufen. Sind damit alle einverstanden? Bedingt aber, soweit ich das Abschätzen kann, eine kompliziertere Verwaltung. Und bedenkt bitte: Ich habe eine andere Struktur als als die VCL. GENAU SO wirds nicht werden, ich kann mich nur annähern.

Die Create-Variente, wie Du se beschreibt, widerspricht der Objekt-Orientierung. besser wäre folgender Ansatz:

Und die Methoden Unregister und Register des Parents manipulieren dann seine FGUIItem.
[edit] Mit SetParent() kann man dann auch nachträglich die GUIItems auf andere Parents verschieben.[/edit]

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Wieder ein Auszug aus der Delphi Hilfe, betreffen TComponent (ich habe nur die Dinge aufgelistet, die mir als wesentlich erschienen):


Wir wollen auch das pure Free Pascal bedienen. Die haben keine IDE.


Das können wir brauchen.


Das könnten wir brauchen, ich neige allerdings zu der Ansicht, dass wir das genausogut selbst machen können und dabei ein wenig mehr Freiheit haben.


Das können wir definitiv nicht brauchen.


Nur eins von 4 relevanten Dingen. Wäre es nicht sinnvoller, die Art der Verwaltung im TGUIItem nachzubilden? Damit kommen wir zurück auf I0n0s' ursprünglichen Vorschlag ^^.

@Sidorion: gefällt mir gut, Dein Vorschlag. Sieht sehr elegant aus. Und man kann dabei schön beim kleinen, einfachen TObject bleiben. Und man versteht es auf Anhieb. Wow!
Traude

Lossy Ex schrieb:


Du hast natürlich recht. Aber: kennst Du die Peanuts? Da sagt Lucy zu Charlie Brown: "Du musst Dir erreichbare Ziele stecken. Geh auf den Werferhügel, ohne hinzufallen." In dieser Situation bin ich derzeit.

Ich würde sagen - immer vorbehaltlich, was Tak dazu sagt - für den Anfang wäre ich sehr zufrieden, wenn man ein paar EINFACHE Widgets nachbilden kann. Das Behübschen kann man auf später verschieben. Am Anfang solllte meiner Meinung nach auf Stabilität und Geschwindigkeit der größte Wert gelegt werden, nicht auf Mannigfaltigkeit. Und wir zielen auf ein allgemeines Userinterface, dass auch für Spiele geeignet ist.
Traude

So natürlich ist das nicht. Ein blindes Huhn trinkt auch gerne mal ein Korn.


He He. Ja kenne ich. Aber man darf natürlich seinen Ball bzw seine Absichten nicht vergessen. Sonst bringt das Erklimmen des Hügels nicht den gewünschten Effekt.


Ich denke man muss dort auch einen Unterschied zwischen Behübschen und spätere echte Features machen. Wobei das größte Problem dabei besteht die echten Features/mögliche Probleme überhaupt erst einmal zu erkennen. Was meinst du warum ich den ersten Versuch meiner GUI verschrottet und noch mal bei 0 angefangen habe. Bestimmt nicht weil ich zu viel Zeit und lange weile habe. Sondern weil es meinen (vielleicht manchmal unter wagen Umständen womöglich bisschen übertriebenen) perfektionistischen Vorstellungen nicht gerecht wurde.

Naja, eine GUI ist ja auch nichts Einfaches. Bei mir waren es Datenbanken. Ich hatte vor ziemlich langer Zeit eine Anwendung geschrieben, die dem DBase nachgebildet war. Tja! Das habe ich voriges Jahr wiederholt (allerdings wars nicht mehr DBase), vor allem, weil ich mich über die Borland-Database-Engine geärgert habe. Ich konnte nichts vom ersten Programm verwenden, musste auch alles verschrotten.

Noch ein kleiner Vorschlag zu implementierung, die Liste sollte nur erstellt werden, wenn das erste Child hinzugefügt wird. Denn schließlich wird ja nur zu den wenigsten items ein unteritem hinzugefügt.
So ähnlich ist das auch in der DelphiX Spriteengine realisiert.

Man könnte Anstelle der TList auch ne TObjectList benutzen, die kann auch ihre Items mitzerstören. Ich weiss allerdings nicht, obs die auch in Freepascal gibt.
Damit hätten wir 2 Punkte vom Tisch:
a) selber ums zerstören der Kinder kümmern,
2. Parent ist dann automatisch immer Owner, was Mißverständnisse bei Unterschieden in Parent<->Owner Hierarchie vermeidet und
III. Wir sparen uns den Component-overhead (Unnötiges COM-Gefummel)
[edit] Die Antwort ist weder a, noch b, noch c, sondern was zum Naschen[\edit]

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

@Sidorion:

Fürs meucheln der FGUIItems habe ich derzeit folgenden Code:



Das heisst: für mich ist damit die Sache eigentlich paletti.
Traude

@The-Winner
Dabei wäre für mich das Kriterium, ob die Liste viel Speicher verschwendet. Dazu muss ich mal in die Unit Classes schaun.
Traude

Wenn Du eine TObjectList nimmst und bei der OwnsObjects auf true ist, schauts so aus:



p.s.: wolltest Du den Code nicht leserlich gestalten?

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

@Sidorion: Nun ja, schon, aber ich weiss auch nicht, ob Free Pascal so etwas hat. Dass muss ich erstmal prüfen. Kommt aber auf die ToDo-List.

@The-Winner: zurück aus der Unit Classes kann ich vermelden, dass eine leere Liste zumindest 3x32 Bit oder auch 12 Byte Speicher braucht. Für jedes Item, das keine Kinder hat, werden also 12 Byte Speicher unnötig verbraucht. Für, sagen wir, 100 solche Items sind das also 1200 Bytes (also rund 1k), für einen Bildschirm; scheint mir keine große Verschwendung zu sein, wenn man die heutigen Speichergrößen in Betracht zieht.

Traude

@Sidorion:
Ich habe die TObjectList im Free Pascal gefunden. Sollte gehen. Jetzt wollen wir noch das Plenum fragen.

Hat jemand irgendwas dagegen, statt TList TObjectList zu verwenden? Würden den Code lesbarer machen.
Traude

qui tacet, prosentire videtur et ceterum censeo Carthaginem esset delendam (Catho, der ältere)

lat.: Wer schweigt, wird als zustimmend angenommen und übrigens bin ich der Meinung, dass Karthago zerstört werden sollte.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.