Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Jul 16, 2025 15:43

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 427 Beiträge ]  Gehe zu Seite Vorherige  1 ... 5, 6, 7, 8, 9, 10, 11 ... 29  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 05, 2006 21:42 
Offline
DGL Member

Registriert: Di Jun 06, 2006 09:59
Beiträge: 474
Was ich immernoch nicht verstehe, wieso du die elemente über addguielement hinzufügen willst, und nicht wie in Delphi
MyButton=TGuiButton.create(MyPanel);
Außerdem weiß ich nicht ob hier ein Dokumenten/Datenorientierten Ansatz sinnvoll ist, da die GUI doch hauptsächlich in Spielen eingesetzt werden soll.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 05, 2006 22:48 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich bins nochmal.
Ich möchte noch eine Zusammenstellung der Punkte nachreichen, die gestern zur Sprache gekommen sind bzw. mir heute bei der Recherche untergekommen sind und auch solche, die mir noch nicht ganz klar sind.

Vorweg möchte ich eines sagen: Es ist ganz offensichtlich, dass wir niemals mit Swing konkurrieren können (Sun hat sicher ein paar mehr Leute, die daran arbeiten, als wir hier haben). Damit unser Projekt ein Erfolg werden kann, scheint mir persönlich folgendes wesentlich:

Man sollte sich vornehmen, das Projekt kompakt und klein zu halten (auch Sun hat das in seinen Vorgaben drin). An die Leserlichkeit des Codes sollten extrem hohe Anforderungen gestellt werden. Und zwar warum: die Utilities, die wir bereitstellen können, werden verhältnismäßig bescheiden ausfallen, verglichen mit dem, was es schon gibt. Andererseits scheint es mir, dass es vergleichsweise viele Pascal-Programmierer gibt. Zwar kaum mehr Firmen, die mit Pascal arbeiten, aber Programmierer die in Pascal ausgebildet sind (möglicherweise rührt das von den Universitäten bzw. Schulen her). Und in diese Leute setze ich meine Hoffnungen. Und daher auch die Forderung, den Quellcode so leserlich wie nur möglich zu machen, weiters auch eine ausgiebige Dokumentation und Beschreibung, wie man eigene GUIItems/Widgets/wie auch immer ableiten kann. und möglichst auch eine englische Übersetzung bereitstellen, das vergrößert den Kreis der Interessenten erheblich, die vielleicht einen Ausbau gewährleisten könnten.

Und nun zu den Punkten:
1) Ich finde, eine Umsetzung MVC sollten wir uns vornehmen (eine Kurzbeschreibung ist in meinem vorigen Beitrag ganz unten bei der Literaturliste und auch ein Link dazu)

2) Derzeit nur ein Renderkontext (nur damit das nicht vergessen wird)

3) Das Projekt ist derzeit nicht threadfähig: jedes übergebene Event wird sofort abgehandelt. Allerdings wurde Swing auch als nicht threadfähig beschrieben (siehe beigelegtes Dokument im vorigen Beitrag), hat mich gewundert

4) Drag and Drop zwischen eigenen Elementen und den Elementen fremder Betriebssysteme (ist eine Idee aus den Swing-Vorgaben und hat nicht wirklich Vorrang aber wünschenswert, mit unseren derzeitigen Vorgaben kaum umzusetzen)

5) Listener(= einer der aufpasst, ob Events ankommen) = GUI-Manager
Der GUIManager hat Funktionen bereitzustellen, die den gesamten Baum effektiv durchsuchen können (Direkt-Pointer, Indizes). Mögliche Suche nach:
1. Identität(Name)
2. Focus
3. Ort
4. Andere Kriterien (z.B. solche, bei denen bestimmte Events stattgefunden haben: On MouseMove nur wenn vorher bei diesem Element ein MouseClick stattgefunden hat, nach einem Vorschlag von Lars, betrifft auch einen Beitrag von I0n0s, er sich mit der Weitergabe von Events beschäftigte)

6) @Evil-Devil: betrifft UML-Format: ein gängiges Bildformat, (JPG,PNG), Danke


UND JETZT GANZ ZUM SCHLUSS HABE ICH NOCH EINE FRAGE.

@ Tak&I0n0s: Mir ist Euer Eventhandling nicht ganz klar.

Angenommen, ich habe ein Key-Down Event, gleichzeitig hat ein gewöhnlicher TButton den Fokus. Und nehmen wir mal an, dieser Button kann mit dem KeyDown-Event gar nichts anfangen, er hat keine Implementierung für OnKeyDown (weder für den User, noch für sich selbst), es existiert hier keine Methode "OnKeyDown". Was passiert dann?

Entschuldigt meinen etwas abgehackten Stil, war ziemlich viel heute, ich werde morgen zu meinem normalen Schreibstil zurückkehren.

Traude


Zuletzt geändert von Traude am Di Dez 05, 2006 23:06, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 05, 2006 22:59 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
The-Winner schrieb:

Zitat:
Was ich immernoch nicht verstehe, wieso du die elemente über addguielement hinzufügen willst, und nicht wie in Delphi
MyButton=TGuiButton.create(MyPanel);
Außerdem weiß ich nicht ob hier ein Dokumenten/Datenorientierten Ansatz sinnvoll ist, da die GUI doch hauptsächlich in Spielen eingesetzt werden soll.


Der Grund ist folgender: Wenn Du die folgenschwere Konstruktion "Create" nutzt, muss auch DU den Button wieder freigeben. In Delphi erzeugst Du doch die Buttons gar nicht. Du gibst sie auch nicht frei. Das macht diejenige Komponente, die für den TButton verantwortlich ist, meist ein TForm.

Den Dokumenten/Datenorientierten Ansatz habe ich mir angesehen, weil er mir bei meiner heutigen Recherche untergekommen ist und ich mal Bescheid wissen wollte. Eine Evaluierung meiner Recherche nehme ich morgen vor. War heute ziemlich viel, und ich bin immer noch nicht ganz durch.

Ich wollte die GUI nicht nur auf Spiele beschränken.

Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 05, 2006 23:13 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Bloß keine umständlichen Listener wie in Swing/Awt. Da gibt's in Delphi die wesentlich elegantere Methoden wie z.B. die Delegates(procedure of object). Überhaupt ist Swing nicht gerade das ideale Vorbild. Java fehlen auch nützliche Sprachemittel wie die Properties oder diese Ereignisse oder Message Methoden die bei Delphi solche Sachen erleichtern.

Zu den Ereignissen:
Das ist doch alles viel einfacher. Jede Komponente hat die entsprechenden virtuellen Methoden wie z.B. OnKeyDown(). Dort wird dann je nach Type entweder OnKeyDown des selektieren untergeordneten Objektes aufgerufen(Container) oder der Button drückt sich oder im Textfeld wird der Cursor bewegt, ....


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Dez 05, 2006 23:18 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2068
Programmiersprache: C++
Traude hat geschrieben:
UND JETZT GANZ ZUM SCHLUSS HABE ICH NOCH EINE FRAGE.

@ Tak&I0n0s: Mir ist Euer Eventhandling nicht ganz klar.

Angenommen, ich habe ein Key-Down Event, gleichzeitig hat ein gewöhnlicher TButton den Fokus. Und nehmen wir mal an, dieser Button kann mit dem KeyDown-Event gar nichts anfangen, er hat keine Implementierung für OnKeyDown (weder für den User, noch für sich selbst), es existiert hier keine Methode "OnKeyDown". Was passiert dann?

Der Button bekommt das Event und reagiert nicht drauf, weshalb sollte er auch?
In der VCL reagiert ein Button ja auch nicht wenn man eine Taste (ausser Enter ;) ) drückt.

Traude hat geschrieben:
Der Grund ist folgender: Wenn Du die folgenschwere Konstruktion "Create" nutzt, muss auch DU den Button wieder freigeben. In Delphi erzeugst Du doch die Buttons gar nicht. Du gibst sie auch nicht frei. Das macht diejenige Komponente, die für den TButton verantwortlich ist, meist ein TForm.

Hast du schonmal Komponenten aus der VCL selber erstellt ohne die "KlickiBunti"-Oberfläche zu benutzen. Das funktioniert genauso.
Vorallem stelle ich mir gerade die Frage, wie ich als Programmierer dann bei der GUI neue Komponenten erstellen soll?
Eine XML-Datei oder die binäre Datei sind dann Overkill.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 08:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Guten Morgen, meine Herren.

Lars schrieb:
Zitat:
Bloß keine umständlichen Listener wie in Swing/Awt. Da gibt's in Delphi die wesentlich elegantere Methoden wie z.B. die Delegates(procedure of object). Überhaupt ist Swing nicht gerade das ideale Vorbild. Java fehlen auch nützliche Sprachemittel wie die Properties oder diese Ereignisse oder Message Methoden die bei Delphi solche Sachen erleichtern.


Mein gestriger Tag lief unter dem Motto "Informationen einsammeln". Ich bin in der "Brainstorming"-Phase, und Du musst bedenken, dass ich nur Pascal kann. Ich bin dabei, über den Tellerand zu schauen. Und sei es nur, um festzustellen, dass das ursprüngliche Konzept besser ist. Ein Ding, das vergleichbares tut, sollte man sich ansehen, sonst muss ich mir immer sagen lassen, dass ich mich eingebunkert habe.

Lars schrieb:
Zitat:
Zu den Ereignissen:
Das ist doch alles viel einfacher. Jede Komponente hat die entsprechenden virtuellen Methoden wie z.B. OnKeyDown(). Dort wird dann je nach Type entweder OnKeyDown des selektieren untergeordneten Objektes aufgerufen(Container) oder der Button drückt sich oder im Textfeld wird der Cursor bewegt, ....


Ja, so ist es vorgesehen. Über Methodenzeiger, wie in Delphi.
Wenn Du etwas über die Vorgangsweise in Swing Bescheid weisst, wäre ich Dir dankbar für Information. Ich habe gesten im Inernet gestochert und bis jetzt nur Allgemeines rausbekommen oder dicke schwere Folianten. Bis zum Kern bin ich nicht vorgedrungen.


I0n0s schrieb:
Zitat:
Traude hat folgendes geschrieben:
Zitat:
UND JETZT GANZ ZUM SCHLUSS HABE ICH NOCH EINE FRAGE.

@ Tak&I0n0s: Mir ist Euer Eventhandling nicht ganz klar.

Angenommen, ich habe ein Key-Down Event, gleichzeitig hat ein gewöhnlicher TButton den Fokus. Und nehmen wir mal an, dieser Button kann mit dem KeyDown-Event gar nichts anfangen, er hat keine Implementierung für OnKeyDown (weder für den User, noch für sich selbst), es existiert hier keine Methode "OnKeyDown". Was passiert dann?


Der Button bekommt das Event und reagiert nicht drauf, weshalb sollte er auch?
In der VCL reagiert ein Button ja auch nicht wenn man eine Taste (ausser Enter Wink ) drückt.


Könntest Du das etwas präzisieren? Wie genau kriegt er das Event? Was ist das für eine Methode? Wie leitet sie das Event an den Button? Wie entscheidet der Button, dass er das Event nicht verarbeitet?


Oder vielleicht andersrum gefragt: Hat bei Euch das Basis-Element ALLE Ereignisse OnKeyDown, OnMouseButtonDown, etc. definiert, und erbt daher JEDES abgeleitete Objekt prinzipiell auch ALLE Ereignisbehandlungsmethoden?


Zuletzt geändert von Traude am Mi Dez 06, 2006 09:25, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 09:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hallo I0n0s,

Zitat:
Hast du schonmal Komponenten aus der VCL selber erstellt ohne die "KlickiBunti"-Oberfläche zu benutzen. Das funktioniert genauso.
Vorallem stelle ich mir gerade die Frage, wie ich als Programmierer dann bei der GUI neue Komponenten erstellen soll?
Eine XML-Datei oder die binäre Datei sind dann Overkill.


Du kannst davon ausgehen, das mir die Vorgangsweise, wie man Komponenten in Betrieb nimmt, bekannt ist.

Ich zitiere mich selbst:

Code:
  1. MyGUIManager:= TGUIManager.Create;
  2. MyWindow:= MyGUIManager.AddGUIItem(TGUIWindow,'Hauptfenster');
  3. MyButton:= MyWindow.AddGUIItem(TGUIButton,'OKButton');
  4. usw.


So generiert man einfach im Programm seine Elemente.

Und jetzt schau noch einmal GANZ GENAU hin: diese Art der Erzeugung ist XML-mäßig. :wink:

Was meine dringende Frage wäre: ist das geeignet für die Skriptspache?

Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 09:34 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
i0n0s hat geschrieben:
In der VCL reagiert ein Button ja auch nicht wenn man eine Taste (ausser Enter ;) ) drückt.

Das ist gelogen. ;-) Beim Drücken der Leertaste wird der Button auch gedrückt. Wenn sie losgelassen wird wird das OnClick ausgelöst. Natürlich kann man immer zu jeder Zeit durch drücken von Escape ein MouseDown oder eine Leertaste wieder aufheben. Um Mal ein wenig zu Spalten. Vor allem solltet ihr auch beachten, dass man auf einen Button mit der Maus drücken kann und falls man sich vertan hat bewegt man die Maus außerhalb und lässt dann los. Das ist gängiges Verhalten.

i0n0s hat geschrieben:
Vorallem stelle ich mir gerade die Frage, wie ich als Programmierer dann bei der GUI neue Komponenten erstellen soll?

Dafür existiert dort ja der übergebene Klassentyp. So lange alle Elemente den selben Konstruktor haben (was sie auch haben sollten) kannst du dann Problemlos mit dem Klassentypen.Create ein Objekt erstellen. Ableitungen davon Reihen sich dort übergangslos ein. Ich benutze die Klassentypen bei solchen Fällen auch ganz gerne.

TObject.Create vs AddGUIItem: Ich denke in erster Linie ist es Geschmackssache. Aber dazu muss ich auch etwas zum Schutz der VCL sagen. Üblicherweise ist es bei ein Formular, wenn dieses nicht automatisch erstellt wird, so, dass es im Konstruktor hergeht und sich seine Objekte aus einer Resource lädt. Beim Freigeben des Formulars werden auch dessen unterobjekte frei gegeben. Wenn ich zusätzlich noch Objekte erstelle dann sorge ich auch dafür, dass diese Frei gegeben werden. Das ist aber leider kein Muss. Aber im Endeffekt sind Regeln ja auch dazu da um gebrochen zu werden. Oder anders gesagt. Nur um sich einer Regel treu bleiben zu können sollte man keinen zu umständlichen Weg gehen. So lange es sinnvoll und kontrolliert abläuft besteht da durchaus ein bisschen Spielraum. Vor allem wenn man die Vor und Nachteile betrachtet. Das ist aber nur meine Meinung.

Code:
  1. MyGUIManager:= TGUIManager.Create;
  2. MyWindow:= MyGUIManager.AddGUIItem(TGUIWindow,'Hauptfenster');
  3. MyButton:= MyWindow.AddGUIItem(TGUIButton,'OKButton');

Der Code wird im übrigen so nicht funktionieren! Das sage ich nicht einfach nur so sondern überlege mal genau. AddGUIItem liefert ein TGUIItem zurück. Aber ein TGUIItem kann nicht direkt auf ein TGUIButton zugewiesen werden.

Funktionieren wird es nur so. Und da hast du entweder ein hartes Casten was bei unachtsamkeit schnell zu fehlern führen kann
Code:
  1. MyButton:= TGUIButton(MyWindow.AddGUIItem(TGUIButton,'OKButton'));

Oder ein sicheres Casten was aber bewiesermaßen nicht das schnellste ist. Und im Falle einer unachtsamkeit schnell zu vermeidbaren Fehlern führt.
Code:
  1. MyButton:= MyWindow.AddGUIItem(TGUIButton,'OKButton') as TGUIButton;

Bzw die "Alternative" alle Objekte als TGUIItem zu betrachten ist wohl ein bisschen umständlich auf die Dauer.

Zu den ganzen Modellen etc. Das ist ja alles ganz schön und gut. Aber helfen euch diese Techniken wirklich? Wie ich in meinem ersten Post schon gesagt habe richtet sich der Aufbau danach was IHR für Features haben wollt und wo diese GUI eingesetzt werden soll. Es spricht überhaupt nichts dagegen sich von anderen System inspirieren zu lassen. Allerdings sollte ihr nicht vergessen, dass diese Systeme alle nicht auf Spiele ausgelegt sind. Und zu viele Informationen können auch genau den entgegengesetzten Effekt haben wie den den ihr haben wollt. Nämlich einen Überblick zu erlangen. Verliert das nicht aus den Augen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 09:35 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Full Ack, mt einer Ausnahme: Die TGUIItems und den Manager von TComponent ableiten und beim Kreieren einer Subnote sich selber als Owner eintragen.
Das hat den Vorteil, dass:
a) wir uns nicht selber um das Zerstüren der Childnodes kümmern müssen und
b) der GUIManager z.B. vom Applikationsobjekt besessen werden kann und man sich nicht um dessen Vernichtung kümmern muss.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 09:36 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2068
Programmiersprache: C++
XD_GUI_Button hat keine Extraprocedure für Key-Events, daher kommt also die Procedure von XD_GUI_Widget zum Einsatz:
Code:
  1.  
  2.   if Visible then
  3.     if Assigned(OnKeyDown_) then OnKeyDown_(key, self);
  4.  

Und die ruft falls existierend die Usermethode auf.

Traude hat geschrieben:
Und jetzt schau noch einmal GANZ GENAU hin: diese Art der Erzeugung ist XML-mäßig. :wink:

Es mag zwar XML-mäßig sein, ist aber inkosistent. Denn wieso sollte ich den GUI-Manager, der eine normale Komponente ist, über Create erzeugen, die anderen Komponenten aber nicht?
Fürs XML-Parsen ist es kein Unterschied. Dann kommt der Code zur Unterscheidung der einzelnen Komponenten nicht ins AddGUIItem sondern in die Procedure zum Parsen.
Und das Argument mit der "Verantwortung" halte ich auch für falsch:
Ich bin der Programmierer, ich bin für alles verantwortlich. Also entweder reicht das Freigeben einer Komponenten aus um alle Kinderkomponenten mitfreizugeben oder nicht. Und die Komponente ist insbesondere der GUI-Manager. Und wer den Pointer auf den GUI-Manager verliert hat eh verloren...

Code:
  1. MyGUIManager:= TGUIManager.Create;
  2. MyWindow:= TGUIWindow.Create(nil, 'Hauptfenster'); //wobei nil für den GUI-Manager steht, alternativ muss immer der Pointer auf den GUI-Manager übergeben werden
  3. MyButton:= TGUIButton.Create(MyWindow, 'OKButton');
  4. usw.


Edit:
Für Skriptsprachen sollte es eh egal sein, weil diese nicht direkt Komponenten erzeugen brauchen, dafür gibt es dann ja noch das Dateiformat.

@Lossy:
:P, dann eben auch auf Leertaste 8)

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 09:46 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Wollts ja nur mal erwähnt haben. :twisted:

PS: Ja ich weiß, dass ich ein perfektionistisch veranlagter Spalter bin. :-P


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 10:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hallo,

Lossy Ex schrieb:
Zitat:
Code:
  1. MyButton:= MyWindow.AddGUIItem(TGUIButton,'OKButton') as TGUIButton;



Bzw die "Alternative" alle Objekte als TGUIItem zu betrachten ist wohl ein bisschen umständlich auf die Dauer.


Ha, Schurke! Du hast mich erkannt. Diese Variante habe ich in meinem ersten Projekt drin. Aber es ist vorgesehen, später dem GUIManager Methoden wie AddWindow, AddButton, usw. einzubauen, weil man das dem Programmierer ja wirklich nicht zumuten darf (eine solche Methode kann man im TGUIItem nicht einbauen, weil ihm TButton gar nicht bekannt sein kann: er ist ja aus ihm abgeleitet).

Ein schweres Argument gegen meine Methode ist: sie wollen es offenbar aus irgendeinem Grund nicht. Das Ist nicht von der Hand zu weisen. Ein Programmierer wird Code, den er nicht mag, auch nicht benutzen. Und weil das auch der innerste Kern von dem ganzen Ding ist, sollten wir uns dafür Zeit nehmen. Ich brüte grade darüber.
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 10:43 
Offline
DGL Member

Registriert: Di Jun 06, 2006 09:59
Beiträge: 474
Wenn du für jeden Itemtyp eine Methode hinzufügen willst, wird das sehr unüberischtlich, außerdem sind dir in der Unit mit demTGuiItem noch nicht alle klassen bekannt. Daher halte ich von dieser Lösung nicht viel. In Delphi ist das so gelöst, dass man dem constructor einen owner übergibt. Wenn dieser Owner<>nil ist, dann wird das objekt beim owner als child eingetragen, und bei der freigabe des owners automatisch mit freigegeben. das ist die lösung die ich bevorzugen würde.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 10:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich dachte, es ist vielleicht der kürzeste Weg, wenn ich beiden Methoden einfach gegenüberstelle:

Zuerst die Create-Variante:
Code:
  1. //********************************************************************
  2. // Initialization
  3. Constructor TGUIItem.Create(AName: String; AParent: TGUIItem);
  4. Begin
  5.    Inherited Create;
  6.    FName:= AName;
  7.    FParent:= AParent;
  8.    If FParent <> Nil Then FParent.FGUIItem.Add(Self);
  9.    FGUIItem:= TList.Create;
  10.    .......
  11.    .......
  12. End;
  13. //********************************************************************


Und dann die Add-Variante:
Code:
  1. //********************************************************************
  2. // Adds one child
  3. Function TGUIItem.AddGUIItem(AGUIItemClass: TGUIItemClass;
  4.                             AName: String): TGUIItem;
  5. Begin
  6.    Result:= AGUIItemClass.Create(AName,Self);
  7.    FGUIItem.Add(Result);
  8. End;
  9. //********************************************************************



Unterschiede: Die Create-Variante manipuliert Daten seines Parents, die Add-Variante manipuliert nur ihre eigenen Daten.

Ich kann sonst keinen Unterschied entdecken. Oder seht ihr noch einen?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Dez 06, 2006 10:56 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Öhmmmm. Ich habe nur die einzigen drei Möglichkeiten aufgezählt. :roll: Mehr gibt es nicht.

Und nichts für Ungut. Die Arbeitsweise mit AddWindow, AddButton finde ich ganz und gar nicht gut. Das kann man machen wenn man genau sagt, dass man nur Fenster, Buttons etc. zur Verfügung hat. Aber sobald man auch nur eine neue Klasse hinzufügt macht man die Sache noch viel komplizierter als es eigentlich nötig wäre.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 427 Beiträge ]  Gehe zu Seite Vorherige  1 ... 5, 6, 7, 8, 9, 10, 11 ... 29  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.011s | 15 Queries | GZIP : On ]