Die Ereignisse werden doch auf dem Weg durch den Baum schon gefiltert. OnMouseDown wird z.B. nur an die untergeordneten Knoten weiter geleitete, die sich auch an der Stelle befinden. OnMouseMove z.B. nur an das Element, bei dem auch OnMouseDown stattgefunden hat (oder mit SetCapture gesetzt wurde).
Dadurch wird es eher schneller weil ganze Äste wegfallen.

Evil-Devil schrieb:


Hm, schon ein zweiter solcher Vorschlag. Das erfordert das Beschaffen von Literatur. Ein gutes Buch ist allemal besser als selbst im Source Code herumzugraben. Kommt auf die ToDo-List.

Evil-Devil schrieb:


Meine Baumstruktur arbeitet genau so: die Welt meines GUI-Elements besteht nur aus sich selbst, seinem Parent und seinen Kindern. Sonst nichts. Es ist sich überhaupt nicht bewusst, dass es Bestandteil eines größeren Ganzen ist. Eine Ameise im Ameisenhaufen, blind und taub.

Die Vorgangsweise mit dem sichtbaren Popup-Fenster /unsichtbaren Parent ist mit meinem derzeitigen Konzept nicht möglich. Muss das mal überdenken.

Evil-Devil schrieb:


Ich brauche mich um Ereignis-Verwaltung nicht zu kümmern bzw. nur sehr eingeschränkt. In den Vorgaben ist vorgesehen, dass der GUI-Manager die Ereignisse "überreicht" bekommt. Die Ereignisse laufen dadurch prinzipiell immer vom Root (das ist der Manager) zum Leaf, dh.Top->Down. Ich behaupte jetzt mal, dass man einen Baum so implementieren kann, dass eine optimale Geschwindigkeit erzielt wird bezogen auf den Haupt-Anwendungsfall, den "Flaschenhals". Einen Haupt-Anwendungsfall habe ich: wie finde ich das Element mit dem Fokus? Daraufhin sollte er optimiert werden.

Evil-Devil schrieb:


Ich würde gerne MouseWheel-Ereignisse auch drin haben.

Evil-Devil schrieb:


Ich kann nicht UML2. Aber ein Klassendigramm wäre sicher etwas Feines. Und ich nehme mal an, Tak sieht das ebenso. Was für ein Output-Format hat UML2? Wie könnte ich Dein Klassendiagramm lesen? Im Augenblick sind wir allerdings noch weit von einer Beta-Version des Grundelements entfernt.

Evil-Devil schrieb:


Free Pascal behauptet von sich, mit Delphi7 kompatibel zu sein. Delphi7 ist voll OOP-fähig.

Evil-Devil schrieb:


Ich bitte Dich! Du sprichst zu einem DAU. Was hat es mit einem Model View Controller auf sich? +++ bitte langsam sprechen, ich bin blond +++

Evil-Devil schrieb:


Es handelt sich um ein spezielles Objekt namens TList. Diese Liste beinhaltet Pointer oder auch Objekte (sind ja auch nichts anderes als Pointer). Diese Liste ist in sich gekapselt, im Debugger sieht man nur den Zeiger, mehr nicht.
Traude

Hallo I0n0s,

I0n0s schrieb:


Du bist ein Listen-Fundamentalist. Ich beginne mich zu fürchten.

Dann nehmen wir eben eine Liste (genauer: das Objekt TList) und ausserdem den Fall zwei.
Traude

Diesen Beitrag von Lars:


rahme ich mir ein und häng mir über den Schreibtisch.
Traude

Sorry das ich so spät antworte aber so etwas passiert, wenn man sich auf den benachrichtigungs Dienst vom Forum vertraut.
Zum glück hab ich noch ein lebenden benachrichtigungs Dienst, er hört auf den Namen I0n0s ^^.

Das mit den Baum ist in Ordnung.
Da das Parent-Child Konzept am ende ein Baum ergibt und ich auch in unserer GUI verdammt gut mit gefahren bin, halte ich es für sehr gut.
Das Konzept erlaubt frühzeitig ab zu brechen, wenn man das richtige Element gefunden hat, welches das Event erhalten soll oder ein visible=False unterwegs auftritt.
Wie I0n0s schon meinte gibt man eifnach jeden Kind-Element die Nachricht weiter(sofern es wirklich weiter gegeben werden soll) und das Kind tut das selbe. Am Ende kann nur ein Element die Nachricht erreicht haben.

Die Idee, ein Widget für den Desktop zu erstellen, würde ich leicht abändern.
Man könnte ein Widget ableiten, welches ein ApplicationWindow ist also ein echtes OS Fenster erstellt.
Somit würde man auch mehere Kontexte ermöglichen können.
Ausserdem würde man damit auch die erstellung von App Fenster abnehmen.

Dies würde natürlich verlangen, das die wrapper unit ein bischen aufgesplitted wird und über inc files realisiert wird.
Somit kann man dann einfach für SDL, Win32, X11 und so weiter eine inc file anlegen und der user muss nur noch die gewollte inc file beim compilieren mit angeben. Wieso ? Es würde nötig sein System Events, Grafik Bibliotheken, Font und ein bischen OS API zu nutzen. Da man dann definitiv nicht mehr vorschreiben kann was genutzt wird, sollte ein Konzept her welches das einfache ersetzen durch anderen Code erlaubt. Dies erreicht man sehr leicht durch *.inc Files.

Wer jetzt grübelt kann einfach mal in mein Attachment gucken. Der Code ist aus X-Dream und zeigt das wrappen auf SDL.

Die Widget erstellen und vernichtung stelle ich mir so vor.

Parent würde alle seine untertanen mit entfernen, da sie abhängig vom Panel sind.

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

Projekte: https://github.com/tak2004

Wah, schon Seite 7...


Eigentlich meinte ich das so wie ich es schrieb. Ich zeig das mal anhand von Swing auf. Da hätte ich als oberstes Objekt erstmal mein Frame. Dieses hat in sich um es mal abzukürzen ein Panel. Auf dem Panel kann ich Elemente platzieren und dort immer weiter verschachteln. Ist prinzipiell nichts anders als ein Baum. Nur wenn ich etwas von einer Baumtruktur lese denke ich zunächst immer an beispielsweise LinkedListen und dergleichen. Ist abstrakt betrachtet nichts anderes als ein Objekt das Referenzen auf seine eingebundenen Elemente hält.


Ok, leuchtet ein, aber was ist wenn du eine Aktion auf einem nicht aktivierten Element ausführen willst? Macht prinzipiell wenig Sinn, aber sowas wie ein InfoPopup kann bei solchen Elementen trotzdem vorkommen. Wobei ich mich gerade frag wozu man sowas bei einer Game GUI benötigen würde...bin schon wieder zusehr beim Desktop...

Wieso kann der Debugger nur den Zeiger zeigen? Das will mir nicht in den Kopf.


Ohne mich fusselig zu schreiben: http://de.wikipedia.org/wiki/MVC Eine kleine Einführung zu dem Thema.


Wie hättest es denn gern? XML, PNG, JPG, DXF, PS , SVG, etc


Sind doch, hatte mein MouseWheel nur nicht MW sondern MR (MausRad) genannt Und eine 3 Tastenmaus fängt bei mir mit dem Mausrad als dritte Taste an. denn das kann man meist nach unten drücken.


Dafür brauchst du dir kein Buch kaufen. Auf den Java Seiten von Sun (http://java.sun.com) und speziell im Desktop Bereich (http://community.java.net/javadesktop/) findet man genug Dokus.

So, war heute mittag ja nicht fertig geworden. Hier mein Rest:

@addElement: Muss das immer vom Parent erstellt werden? Eine FactoryMethode ist schön und gut, aber warum nicht direkt eine Instanz des Objekte erzeugen und dies manipulieren und dann übergeben. Oder wie kann man nach dem derzeigen Weg nach dem hinzufügen das Element auf elegante Weise manipulieren? Zur Laufzeit wie auch zur Programmerstellung.

Ich glaub das wars erstmal

Evil

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

Normal zeigt er nur einen Pointer weil eben nur ein Pointer drinne steckt. Man kann aber Ausdrücke überwachen und dort kann man auch Casten (kein as) oder funktionen ausführen etc. Also es ist vielleicht nur ein zusätzlicher Zwischenschritt aber das ist kein Problem für den Debugger.

Weil die Zeiger in der Liste untypisiert sind, also schlicht Pointer. Darum hat er keine Chance, die richtige 'Klassenschablone' drüberzulegen. Und wenn er das nicht kann, dann kann er auch nicht die Eigenschaften darstellen.

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

Vielleicht geht es mit einer TObjectList besser. Wenn man weiß, dass es ein TObject ist, kann man auch den genauen Type feststellen.

Gibt es keine Möglichkeit eine typisierte Liste anzulegen? Nur mal so frag -.-
Denn man kann doch davon ausgehen das ein Debugger auch nur den Weg des Programmes folgt und dann spätestens dann weiß was wo in der Liste steht. So kenn ich das von Java halt her. Deswegen ist das Debuggen auch um einiges langsamer...

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

Um mich mal zu wiederholen. Es ist im Debugger möglich! Es ist zwar nicht sofort sichtbar sobald man die Maus über eine Variable bewegt aber mit einem kleinen Handgriff ist alles drin. Aber damit fahre ich seit Jahren ohne Probleme!

Eine Objectliste würde auch nichts bringen da er so nur die Eigenschaften eines TObject anzeigt.

Evil: Typisierte Listen. Nicht direkt. Entweder ein Array von einer Klasse oder eben etwas was man selbst geschrieben hat. Aber zu 95% genügt auch die Objektliste oder eine normale Liste. Es gibt aber keine Möglichkeit im Code zu definieren wie ich habe eine Liste des Typ XYZ. Muss man wenn man so etwas unbedingt haben will alles per Hand machen. Ist aber normal nicht nötig.

PS: Selbst wenn sich an dem Pointer keine Klasse befinden würde und man es als Klasse castet dann bekommt maximal der Ausdruck eine Exception. Das beeinträgt das debuggen aber in keiner Weise.

Natürlich geht das, aber dann muß man das halt selber machen. Delphi kann Templates bzw. Generics nur über Umwege. TObjectList ist soweit typisiert wie ArrayList, aber List<T> gibt es (noch) nicht.

Hallo,
ich habe eine typisierte Liste einmal gebaut. Es war ein Ding namens TStdItem und ich habe es zu dem Zweck geschrieben, das GrundItem für eine typisierte Liste zu sein, die TObjects Laden und speichern kann, wobei man nur eine Lade- und Speicherprozedur schreiben musste, um jedes mögliche Objekt auf einfache Weise zu laden und zu speichern mit kleinen eingebauten Datenbank-Funktionen. Aber das brauchen wir hier bestimmt nicht. Wenns denn so ein unbedingter heftiger Wunsch ist, komme ich auch mit Listen zurecht, keine Sorge.

Hallo Tak,
ich freu mich, Text von Dir zu sehen.
Wie es scheint, interessiert dieses Thema einige Leute. Ich werden mich bemühen, alle die Perlen, die heute auf mich heruntergepurzelt sind, einzusammeln und anzuordnen, bzw. zu erfassen, was der allgemeine Tenor ist.

Und ich möchte jetzt auch noch einen Wunsch einbringen. Ich wünsche mir, das die GUI (die ich persönlich auch als allgemeine GUI verstehe, nicht ausschliesslich nur für Spiele) einen Quick-and-Easy-Modus behält. So etwas wie FPC starten, GUI draufwerfen, Ein Panel + 2 Knöpfe, fertig.
Traude

Meine Herren (Damen sind leider keine da)
ich melde mich für heute ab, um einen Bericht zu basteln. Ich werde mir zusätzlich Swing und MVS ein wenig anschauen. Ich werde heute abend berichten. Allerdings kann ich nicht garantieren, bis heute abend fertig zu sein.
Traude

Guten Abend.
Folgende Dinge habe ich heute gemacht:

1) Mir Model View Controller(MVC), Document View Model und Swing angesehen (ich bin noch beim Sichten, Auswertung folgt)
2) Mir eine Beschreibung von Swing aus dem englischen Wikipedia übersetzt und mit unserer Vorgabe verglichen /Dokument liegt bei: erste Seite ist der Originaltext, zweite Seite die Übersetzung mit Vergleich)
3) Die Dokumentation der Java Beans heruntergeladen, bin aber erst beim Lesen
4) Die Funktionen des GUIItems nochmals aufgelistet, wie sie sich mir jetzt darstellen (siehe unten) wegen MVC
5) Einen Auszug aus dem GUIItem dargestellt(siehe unten), besser gehts nicht, kann eine Liste nicht in ein Published Property packen (Arrays übrigens auch nicht)
6) Eine Mini-Web-Literaturliste (ganz unten) aufgestellt, wenns jemanden interessiert
7) Eine kleine Zusammenstellung der gestrigen Punkte folgt in Kürze


----------------------------------------------------------------------------------------------------------------------------------------------
Um das MVC anzuwenden(was sehr empfehlenswert wäre), muss man erst einmal die Funktionen der GUIItems darstellen:

Funktionen des GUIItems (siehe MVC) oder auch: was soll es können?
1. Darstellungsfunktion1 = Reaktionsfunktion auf Benutzeraktion (z.B. Benutzer klickt mit der Maus auf ein Element, und das Element zeigt mit einer sichtbaren Reaktion, dass es sich auch betroffen fühlt und ändert gegebenenfalls den Zustand seiner internen Daten)
2. Darstellungsfunktion2 = Reaktionsfunktion auf Programmfunktionen (Idee aus dem Document-View Model: Das GUI-Item stellt eine Schnittstelle bereit, die der User mit einem Objekt verbinden kann, sodass das Element bei Änderung des Zustands des Objekts auch seine sichtbare Erscheinungsform ändert, dh. es soll eine OnChangeData-Reaktion haben
Anmerkung zu den Darstellungsmöglichkeiten: Die Darstellungsmöglichkeiten sollen auf mehrere mögliche Zustände ausgeweitet werden: z.B. aktiv/inaktiv, bereit/nicht bereit (Stichwort: OnHover), fokussiert/nicht fokussiert
3. Baumfunktion1: Austausch von Daten mit Root, Parent und Children (z.B. im Hinblick auf Events, können aber auch andere Daten sein)
4. Baumfunktion2: Aufrufen von Methoden von Root, Parent und Children (um zu gewährleisen, dass Funktionen über das Root-Element aufgerufen werden können und sich über den ganzen Baum - oder auch Teile davon - fortsetzen (z.B. Draw)
5. Lade/Speicherfunktion (im Sinne des MVC (siehe oben) in ein Objekt auslagern

----------------------------------------------------------------------------------------------------------------------------------------------------
AUSZUG aus dem TGUIItem: betrifft die SubNodes, Zweck: Klarstellung (I0n0s?)
(unter Einhaltung obiger Vorgaben bzw. der Übereinkommen mit der Community)
Eigentümer des (einzelnen) TGUIItems (Gewalt über Leben und Tod, sprich: Create und Destroy) ist sein Parent
Manipulierer des (einzelnen) GUIItems (Gewalt über die Eigenschaften des GUIItems): kann jeder sein (Zugriff über ein Array-Property kann der Compiler nicht), biete daher eine Funktion GetGUIItem an


Achtung: Die Funktionen AddGUIItem und DeleteGUIItem sind Methoden des TGUIItems,
daher muss das Anlegen der GUIItems prinzipiell so aussehen:





---------------------------------------------------------------------------------------------------------------------------------------------
Literatur aus dem Web:
1. MVC - Model View Controller bezeichnet ein Architekturmuster zur Aufteilung von Softwaresystemen in die drei Einheiten: Datenmodell, Präsentation und Programmsteuerung. - Probleme mit OOP wegen Datenkapselung (Quelle: Wikipedia, Stichwort MVC)
2. DVC - DocumentViewModel: Das Document-View-Modell fordert die strikte Trennung von Daten (Document) und ihrer graphischen Darstellung (View). Quelle: http://www.pi.informatik.tu-darmstadt.de/se1997/microperls/doc/Entwurf/designpatterns.html
3. JavaBeans: http://java.sun.com/products/javabeans/docs/spec.html
4. Features of the Java Foundation Classes: http://java.sun.com/docs/books/tutorial/uiswing/start/about.html