@Sidorion:

Aber, aber.
Wer wird denn so zerstörerisch veranlagt sein.

@Off Topic: Wenn Du Oma Wetterwachs kennst, dann kennst Du vielleicht auch Mustrum Ridcully oder Sam Mumm?

Meine Lieben,
da anscheinend keiner mehr da ist, verabschiede ich mich für heute auch.
Traude

Erstmal:
2 Seiten in 9 Stunden ...
Wir sprengen Flow die Datenbank...


Ok, Danke.


Wer nicht warten kann hat keine Geduld

Und ich bin jetzt da, zumindest noch 15 Minuten
Ähm, b.t.T.:
Bin auch für Objectlist, die nimmt uns Arbeit ab, also gut

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

Erstmal zum Mailverkehr.
Ich werde noch bekloppt mit der automatischen Mailbenachrichtigung aber ich hab ja I0n0s .

Ich muss mal ein bischen alten Kaffee aufkochen, da ich ziemlich spät rein geguckt hab.


Ist eine sehr anstrebenswerte sache.
Wie sie genau realisiert wird ist momentan weniger interessant.

Wichtig ist doch folgendes.


Das das TGUIWidget dann im constructor dem parent den owner zuweist und das Widget hinter parent als child self bekommt ist dann ne sache, wie der programmierstiel dann ausfällt.

Um nochmal auf das Eventsystem von unserer GUI zu sprechen zu kommen.

Im Manager sind die basis Events also Taste drücken,Maus drücken, Maus bewegen und aus diesen wird dann vom Manager die speziellen events wie Drag&Drop, Paint, MouseOver,... abgeleitet. Der Manager ruft nun alle childs(was übrigens über TObjectList realisiert ist) auf wo die Bedingungen für den jeweiligen Event stimmen(MouseOver sollte das Element auch wirlich unterm Cursor liegen). Sprich es wird das Event von TXD_GUI_Widget aufgerufen und darin ist verankert, dass es deren Kinder auf den Keks geht(rekursiv halt). Diese Variante geht in die Tiefe und nicht in die Breite und ist daher wesentlich schneller am Ziel als andere Variante. Sobal ein Widget sagt, ich bin ein armes Schwein und habe keine Childs, gibt es zurück das er den Event entgegennimmt und alle Schleifen werden sofort beendet. Ein Widget was kein Input verarbeiten kann, wird das Event einfach ignorieren und der Event ist gegessen.
Drag und Drop und ähnliche dinge sind auch leicht gelöst. Eine Variable LastWidget, im Manager, kann vom Drag Event belegt werden und vom Drop event ausgewertet werden und eventuell ein AcceptDrop Event auslösen.

Wenn eine Komponente vernichtet wird, dann muss auch alles was drunter liegt also jedes Child und deren Child gekillt werden. Sowas wird im destructor rein gepackt und wird auch rekursiv gelöst.

Ein Bildformat hat hier übrigens wenig verloren, denn welches Bildformat verwendet wird ist nicht die Sache der GUI sondern des externen Textur Managers.

Da es ein Standard Binding geben sollte, z.B. SDL,SDL_Image,SDL_TTF und libXMLparser wäre es praktisch eine Interne Struktur zu erstellen. Sprich für Formulardaten nimmt man nicht XML sondern es wird ein Baum oder ähnliches verwendet und eine Schnittstelle kann dann ein parser für XML, binäres XML, ini oder ähnliches die Daten liefern. Das selbe sollte auch für Texture, Fonts und Themes gelten.

Somit ist der Kram aus der GUI raus und man muss ledeglich mal ein paar bindings für gängige libs erstellen(um es einsteigerfreundlich zu machen).

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

Projekte: https://github.com/tak2004

Wegen dem Klassendiagram hab ich ne allgemeine Frage zu Delphi. Unterstützt Delphi in irgendeiner Weise Mehrfachvererbung oder Interfaces? Oder totale Einzelvererbung ohne Interface Möglichkeiten?

_________________
(\__/)
(='.'=)
(")_(")

Also Delphi unterstützt Interfaces aber keine Mehrfachvererbungen. Eine Klasse kann mehrere Interfaces unterstützen aber nur von einer Klasse abgelitten sein. Wenn ich jetzt wüsste was "totale Einzelvererbung" wäre könnte ich dir dazu evtl auch etwas sagen.

Aber eine normale Vererbungshirarchie sollte dafür aber eigentlich vollkommen ausreichen. Also ohne interfaces. Es muss ja schließlich auch Platformunabhängig sein.

Mit totale Einzelverbung meinte ich eine Vererbung die nicht auf Interfaces zurückgreifen kann. Da man mit Interfaces eine Art der Mehrfachvererbung nachbilden kann Werd mich am Wochenende mal zu einem ersten Klassendiagramm hinreißen lassen und hoffentlich schon beim ersten Ansatz an alles wichtige denken.

_________________
(\__/)
(='.'=)
(")_(")

Interfaces selber können Mehrfachvererbung.

Interfaces haben Vor- und Nacheile:
Nachteil: Bei Verwendung von Interfaces muss man komplett umstellen, da interfaces eine Referenzierungszählung haben, die bei gleichzeitiger Verwendung des Objekts über Interface und Klasse durcheinanderkommt. (z.B.: bei Erzeugung und Zuweisung auf Klasseninstanzvariable wird die Instanz sofort wieder zerstört)
Vorteil: Man spart sich komplizierte Klassenhierarchien, so kann man z.B.: jeden Eventtyp in ein Interface packen und das Widget hat das Interface oder nicht. Das ist von der Klassenhierarchie unabhängig.
Die Bearbeitung des Events kann man dann sogar in eine Delegatenklasse auslagern, die sich um die Implementierung des Interfaces kümmert. Ich hab das mal für ein XML-Streaming gebaut, bei dem alle published-Propertys in ein XML-File geschrieben wurden, ähgnlich wie das die Delphi-eigene streaming-Geschichte macht. Um eine Kalsse dann XML-Streaming-fähig zu machen genügt es, ihr das Interface zu verpassen und ne Instanz der Delegatenklasse anzulegen.

_________________
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.

Die Referenzzählung kann man ja ausschalten wenn man AddRef und Release entsprechend implementiert. Ist eigentlich keine gute Sache, dass interfaces immer von IUnknown erben. Bei FP kann man das umstellen.

Also ist das folgende in Delphi eher weniger sinnvoll? Mal von der allgemeinen Sinnlosigkeit dieser Zusammenstellung im Beispiel abgesehen ;D
Hoffe das Beispiel ist selbsterklärend genug.

_________________
(\__/)
(='.'=)
(")_(")

Guten Morgen.
Mit Interfaces müsste ich mich erst näher beschäftigen. Habe die Interfaces immer links liegengelassen, weil ich sie für eine Umsetzung des Windows-COM-Konzeptes hielt.

Sidorion schrieb:

Klingt mir gar nicht gut. Habs aber eigentlich nicht verstanden. Ich erzeuge das Interface und weise es z.B. einer Variable eines TObjects zu (vulgo: das Objekt soll ein Interface besitzen), dabei wird es zerstört?

Sidorion schrieb:

Das ist doch auch bei den Methodenzeigern so. Was ist der prinzipielle Unterschied? 'Tschuldigung, habe noch nicht mit Interfaces gearbeitet.


Weißt Du wo der Unterschied liegt, wenn ich zB. für ein TGUIItem ein Interface habe, welches das XML-Streaming erledigt, oder aber ich baue mir ein Objekt TXMLDataProvider? Eine fällt mir gleich selbst ein: eine Schnittstelle muss es natürlich geben. Und die muss natürlich vorher vereinbart werden. Könnte man aber doch machen?


Allerdings ist das Thema AKTUELL, weil grade bei mir die Frage auftaucht, wie die UserEvents nun wirklich zu implementieren sind, als Prozedurzeiger oder als Objektzeiger oder beides.

Traude

@LarsMittendorf: Also vom Ausschalten des Standardverhaltens halte ich nu garnix, zumal die GUI ja von Leuten verwendet werden soll, die nicht wissen, dass wir das geändert haben. Ich hab das früher auch gemacht, aber wenn man sich an gewisse Regeln hält, passiert garnix.

@Traude: Intern passiert hier folgendes:

Beispiel1: mit Klassenreferenz:

Wenn TMyObj ein Interface hat, wird beim Konstruieren (innerhalb des Konstruktors) das Interface mit angelegt. Dieses hat einen Referenzzähler, der auf 0 initialisiert wird. Soweit ist noch alles gut. Jetzt wird die erzeugte Instanz auf die Klassenvariable oMyObj zugewiesen. Dabei wird der Referenzzähler aber nicht incrementiert, da oMyObj eben eine Klasseninstanz ist. Nach der Zuweisung wird nun geschaut, ob der Referenzzähler =0 , wenn ja, wird die Instanz freigegeben und oMyObj zeigt in die Pampa.

Beispiel2: Mit Interfacereferenz:

Hier passiert im Konstruktor das gleiche, wie vorhin, aber das oiMyObj eine Interfacereferenz ist, wird der interne Referenzzähler hochgezählt und ist nach der Zuweisung nicht=0 und die Instanz bleibt bestehen.

Ich kann also instanzen von TMyObj erzeugen, aber wenn nicht mindestens ein Verweis auf mindestens ein Interface existiert, wird die Instanz zerstört.
Mir ist noch ein Vorteil eingefallen: Alle Interfaces des selben Klassentyps sind zuweisungskompatibel:

_________________
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.

Die Schnittstelle nach aussen, also zur script engine und zu dingen wie xml loader, hab ich in XD_GUI so gelöst.

Nun sind alle properties im published bereich nach aussen nutzbar.
Die TXD_RTTI Klasse ist eine Klasse die dann Funktionen bietet um Werte zu lesen und zu schreiben+ein paar anderen sachen.
Der XML Loader(der nicht in die GUI gehört) kann dann ein Widget erstellen und über die von der TXD_RTTI Klasse gelieferten funktionen einfach 2 strings(name der variable und wert) übergeben und fertig. Somit kann man in den GUI Widgets rumspielen wie man lustig ist. Die von der Klasse gelieferten Informationen werden immer nutzbar nach aussen gelegt.

Die RTTI daten werden eh für jede Klasse angelegt und dann sollte man sie doch auch nutzten.
Meine Idee für die GUI würde so aussehen.

TRTTI
Besitzt Funktionen, um published properties zu lesen und zu schreiben.
Kleine anmerkung nebenbei, Delphi und FPC unterstützen nicht alle arten von Properties.
FPC kann momentan noch keine properties vom typ record und bei Delphi gibt es auch ein paar Typen.
Allerdings werden alle wichtigen Typen unterstützt(klassen,methoden,zahlen,zeichenketten,sets,interface,object,...).

TRTTIManager
Man kann Klassen die von der TRTTI Klasse abgeleitet wurden registrieren und entfernen.
Es gibt eine Funktion die anhand eines Strings erkennt welche registrierte Klasse gemeint ist und erstellt eine Instanz davon.

Das spart echt viel programmier Zeit, für nutzer der GUI und für die entwickler der GUI.
Ausserdem kann man so ein völlig neue GUI Version nutzen ohne sein eigenen Code ändern zu müssen.

Wer jetzt grübelt, wie so etwas aussehen kann, hier mal ein kleines Beispiel.

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

Projekte: https://github.com/tak2004

Ob es so sinnvoll ist, dass man zum Lesen/Schreiben von Properties von einer Klasse ableiten muss? Immerhin ist dann die einzige Möglichlichkeit von einer Klasse zu erben schon belegt. In der VCL gibt's dafür dann ja auch die TReader/TWriter Komponenten und Serialisierung ist eigentlich nirgendwo weder bei Java noch bei .Net direkt in der Klasse.