Hallo Lossy,
das mit der Y-Koordinate mache ich schon immer automatisch. Hab mich an den Koordinatenursprung unten links gewöhnt, ist so schön anschaulich. Dadurch muss ich aber auch immer die Textur flippen, wenn ich Deine glBitmap benutze.
Ich denke mal, wir sollten das System nehmen, das alle kennen. Und das läuft also vermutlich auf den Koordinatenursprung oben links hinaus. Seufz!

Hallo,
Ich stehe gerade wieder vor einem prinzipiellen Problem. Ich habe jetzt den ganzen Thread noch mal durchgeackert, um die Infos zusammenzustellen. Dabei bin ich auf Taks Schnittstelle nach außen gestoßen. Er realisiert die Eingabe/Ausgabe der Felder eines GUI-Elements mit Hilfe von Published Properties. Dabei werden Feldinhalte des Objekts gelesen/geschrieben, das Ganze dient zur Unterstützung des XML-Streaming und der Skriptsprache und hört sich sehr praktisch an.

Folgende Info habe ich dazu aus der Delphi-Hilfe (Stichwort published):



In meinem Hinterkopf geistern dabei die ganze Zeit die Begriffe Left,Top,Width,Height herum.
Was hat das damit zu tun? Nun, ich frage mich ernsthaft, ob wir mit den vier Werten auskommen oder ob wir uns damit nicht eine Beschränkung auferlegen, die uns später noch leid tun wird (Lossy Ex hat mir einen Floh ins Ohr gesetzt, und der sticht jetzt). Wenn man aber kompliziertere Datentypen (z.B. eine Liste von Punkten) verwendet, kommt man mit diesen Published Properties in Schwierigkeiten. Klartext: die Methode, wie Tak sie anwendet, ist dann nicht mehr möglich. Ich denke dabei an Spiele, die kompliziertere Fenster haben und mit dem vorliegenden System auch auskommen müssen, siehe das letzte Projekt von Sascha Willems.

Daher noch mal die Frage: wird man mit Left,Top,Width,Height (bzw. mit vier Integer-Werten) auskommen?

Es ist damit folgendes möglich:
· einfache Linien
· Vierecke (grundsätzlich sind mit Left,Top,Right,Bottom sowohl rechtwinkelige als auch schiefwinkelige Vierecke möglich)
· Regelmäßige Vielecke, die im Viereck eingeschrieben sind
· Ellipsen/Kreise, die im Viereck eingeschrieben sind
· vielleicht noch was, was ich übersehen hab

Was nicht möglich ist: unregelmäßige Polygone darzustellen, denn das bräuchte eine Punkteliste, gar nicht zu reden von einer Texturkoordinatenliste.
Ihr könnt jetzt natürlich sagen: schmeißen wir eine Textur drauf und gut ist. Aber ist das wirklich so?
Traude

Dein gedankengang geht in eine Richtung die ist beängstigent.^^
UV Koordinaten haben nichts mit den Published Properties zu tun.
UV Koordinaten haben garnichts mit der GUI zu tun, sondern mit dem Wrapper für Zeichenfunktionen.

Ich sollte das mal ein bischen prezisieren und auflösen.
Als Published Properties werden alle Methoden und Variablen angegeben die nach aussen erreichbar sein müssen.
Der fehlende Support von Arrays hab ich über Funktionen gelöst und das schreiben auf Listen hab ich über ein Property mit dem Typ und als write funktion kommt dann eine Funktion die dann die Liste um 1 erweitert.
Das es ausreicht zeigt ja die XD_GUI und deren Script und XML anbindung(für Theme und Formulare).
Ausserdem denke mal an VCL die Delphi IDE verwendet auch die RTTI daten und die Properties werden auch verwendet um die Einstellungen für die VCL zu machen. In diese Richtung braucht man keine Panik schieben.

Allerdings sollte ich noch folgendes zu sagen. Durch das verschieben nach Published, fallen größere Daten an und diese werden in der größe der Binary zu Buche schlagen. Was bedeutet, mit jedem Widgettyp kommen ein paar Bytes mehr dazu.
Die ersparnisse im Code, für die Loader der Formular und Theme Datein wird das aber sehr stark ausgleichen.

Mein XML Theme Loader ist knapp 200Zeilen groß und mein XML Formular Loader ist knapp 240Zeilen lang, wobei er nach hier vorgeschlagender realisierung noch 20-30 Zeilen verlieren würde. Beide sind völlig unabhängig von änderungen im Widget umfang oder von den Widget selber.

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

Projekte: https://github.com/tak2004

Beliebige Formen kann man einfach realisieren.
1) Die Komponenten zeichnet eben nicht das ganze Rechteck, dass ihr zu steht voll.
2) Für Maus-Ereignisse benötigt man noch eine zusätzliche Methode function HitTest(p:TPoint):Boolean mit der geprüft werden kann, ob der Punkt zur Komponente gehört. Die Standard Implementation prüft nur auf Rechteck, kann aber überschrieben werden.

Beim Abspeichern der Komponenten ist man mit einer externen Klasse besser dran, weil man so von verschiedenen Quellen laden bzw. Erweiterungen/Änderungen im Format vornehmen kann. Dann ist die GUI nicht so stark an ein Format, in diesem Fall XML, gebunden.

Warum wird eigentlich nicht TComponent als Grundlage benutzt? (steht das schon auf den Seiten vorher?) Das bietet schon eine Verwaltung untergeordneter Objekte und kann auf Streams gespeichert werden. Für Properties die nicht als published deklariert werden können gibt es die Methode DefineProperties in der Klasse TPersistent, von der alle(?) Objekte mit published properties in der VCL abgeleitet sind. Dann müßte man nur noch den TReader/TWriter anpassen, dass er keine Delphi *.dfm sondern xml ausgibt bzw liest.

Tak schrieb:


Es war reichlich spät gestern. Vielleicht war ich deswegen vernagelt. Ich schiele dabei auf den Theme Manager: angenommen, ich will ein kompliziertes Fenster bauen. Und ich möchte eine Textur dazu verwenden. Da könnte ich doch auf die Idee kommen, Punkt- und Texturkoordinaten laden zu wollen. Und dazu brauche ich diese Published Properties, sonst funktioniert das Laden nicht, richtig? Aber Punkt und Texturkoordinaten muss man in Arrays oder Listen haben. Und diese werden von den Published Properties nicht unterstützt, ergo kann ich sie auch nicht laden und daher haben sie in meinem Konzept auch keinen Platz. Ich habe nur sinniert, ob das nicht vielleicht ein Fehler ist.


Aber das kann man zum Laden/Speichern nicht benutzen, oder?

Allerdings finde ich auch, das Deine Art zu Laden und zu Speichern höchst praktisch ist, keine Frage.

Tak schrieb:

Die VCL hat aber nicht den Ergeiz, auch Spiele bedienen zu wollen. Wenn man die VCL-Fensterchen verwendet, schauts ein bisschen nach Buchhaltung aus.

Tak schrieb:

Da stimme ich Dir zu.

Lars schrieb:


Du bist mir echt unheimlich. Du präsentierst mir die Lösung in drei Sätzen, und ich brauche eine ganze Seite, um meine Frage zu formulieren.

Das heißt: Wenn jemand ein kompliziertes 2D-Objekt haben möchte, findet er ein Rechteck vor, und muss mit diesem auskommen. Man bietet ihm sozusagen bloß ein viereckiges Plätzchen, mit dem er tun kann, was er will. Allfällige Punkt-/Texturkoordinaten muss er per Programm generieren, händisch oder automatisch, z.B. mit trigonometrischen Funktionen (Sinus/Cosinus etc.). Eigentlich könnte er für seine Punkt/Texturkoordinaten einen eigenen Loader einbauen (Ich sage jetzt nicht, dass das sinnvoll ist, sondern nur: es ist möglich). Und er sollte seine Maus-Hit-Methode anpassen. Ich kann jetzt z.B. auf diese Art ein Fenster in Form eines O erzeugen und dafür sorgen, dass MausHit nur "Ja" sagt, wenn auch wirklich nur das O angeklickt wurde, nicht der ganze rechteckige Bereich. Wenn ich dann noch eine teilweise transparente Textur verwende, kann ich durch das O in der Mitte durchsehen. Ich glaube, ich habe das TGUIItem bisher zu "statisch" gesehen (ich war wirklich "vernagelt"). Das ist es ja gar nicht! In Wirklichkeit kann man damit tun was man will. Man könnte ein abgeleitetes Element zu einem ausgefeilten Programm ausbauen.

Und ich kann Taks Lademethode verwenden.

Lars schrieb:

Seh ich auch so.

Lars schrieb:

Ich habe ein paar Seiten vorher das TComponent für unsere Zwecke evaluiert. Und dabei kam raus: es hat zuviele Funktionen, die wir gar nicht brauchen. Aber ich müsste das jetzt eigentlich nochmal tun, weil das ein Aspekt ist, den ich damals gar nicht berücksichtigt habe.
Traude

Ich habe ja auch ein paar seiten vorher angeprangert, das Formularloader intern eine Struktur sein soll und von externem Code dann gefüttert wird. Da ging es darum, dass jemand Binäre XML files haben wollte.



Da müsste mal in richtung FreePascal geforscht werden, ob es das auch so implementiert hat und ob das Interface von Delphi immer gleich geblieben ist.

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

Projekte: https://github.com/tak2004

Tak schrieb:


Ich kann das übernehmen für folgende Versionen: Delphi Version 5 und 7 und Free Pascal Version 2.0.2. Bei Delphi-Versionen, die höher sind als Delphi 7 muss ich passen. Dauert ein bisschen.
Traude

http://www.freepascal.org/docs-html/rtl/classes/tcomponent.html wer mal mit der Delphi Hilfe vergleichen will.
Ich hab kein Delphi auf mein neuen Rechner und kann dies nicht überprüfen.

edit:
http://www.freepascal.org/docs-html/rtl/classes/twriter.html
http://www.freepascal.org/docs-html/rtl/classes/treader.html

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

Projekte: https://github.com/tak2004

Hallo Tak,
ich setze mich grade hin und fange damit an, konnte bisher nicht. I0n0s hat mir mal einen Film namens "Flutsch und weg empfohlen, aber das funktioniert bei mir nicht, weil die Natur die Beine von Ehefrauen kürzer gemacht hat damit sie nicht entkommen können. Hungrige Familienmitglieder sind gefährlich.
Traude

Ich dachte mir, das Beste wäre, die beiden Source Codes direkt zu vergleichen.

In der Beilage findet ihr:
--- ein Textfile mit dem Interface-Teil des TComponent von FPC Version 2.0.4 (Download-Datum: 4.11.2006)
--- ein Textfile mit dem Interface-Teil des TComponent von Delphi7 (ist eine veraltete Delpi-Version)

Fazit: sie sehen verflixt gleich aus.

Ohne jetzt genauere Untersuchungen angestellt zu haben, scheint die Verwendung von TComponent in Free Pascal gut möglich zu sein. Was ich aber unbedingt vermeiden will: zu großen Overhead mitzuschleppen, den wir gar nicht brauchen. Das bedeutet, dass ich TComponent wirklich durchackern und mir im Einzelnen anschauen muss, was können wir verwenden und was nicht. Und das braucht bestimmt ein paar Tage, wenn es fundiert sein soll.

Was wollt Ihr, dass ich tue?

Traude

Ich bins nochmal.

Ich habe das eigentlich schonmal gepostet, aber vielleicht mit anderen Schwerpunkten:

Das sagt die Delphi-Hilfe zu TComponent:


Das brauchen wir eigentlich nicht (Free Pascal hat keine IDE, Taks RTTI-Objekt müsste das Gleiche machen).


Das macht das TGUIItem ohnehin schon.


Delphi-Hilfe zu TPersistent: siehe ganz unten. Ich kam zum Schluss, dass die Streaming-Funktion von TPersistent, die xfm oder dfm Dateien schreibt, nicht brauchbar ist für unsere Zwecke. Und Tak HAT eine brauchbare Funktion bereits fertig.


Das wollen wir nicht: nicht plattformunabhängig.


Die Delphi-Hilfe zu TPersistent:

Das können wir nicht brauchen. Unsere Vorgabe ist XML/Binary


Ich komme also hier - weil ich diesmal ins TPersistent hineingeschaut habe - , umso mehr zu dem Schluss, dass uns TComponent nicht helfen wird. Das war für mich der Grund, TComponent gar nicht näher anzuschauen. Meine Empfehlung ist daher, nicht TComponent zu verwenden, sondern Taks Methode in Betracht zu ziehen.
Traude

Ich glaubr nicht, dass dies notwendig ist.
Es reicht, wenn der Funktionsumfang sich ähnelt.
Die Frage ist wie sieht es nun in der Praxis aus, also wie würde man nun Daten in die Klasse lesen und wie kann ein anderer Code Daten von der Klasse erhalten.

Was müsste die GUI und TComponent können ?
Der GUI Manager müsste über eine Funktion, die eine ID(eindeutiger name des Widgets) erhält, die Komponente zurück geben und dann die Daten der Komponente per name(string) zugreifbar machen(lesen und schreiben).
Des weiteren müsste man eine Klasse mit einem Namen registrieren können und dann Instanzen davon erstellen lassen können.
Wenn dieses gegeben ist, dann kann man Scriptsprachen und Formularloader damit realisieren.

Das registrieren einer Klasse mit einem Namen und die erstellung von Instanzen ist kein Problem und hat nichts mit Tcomponent zu tun. Genau so ist das finden eines Widgets, anhand einer ID, auch nicht TComponent abhängig sondern alles vom GUI Manager.

Was bleibt also übrig ?
Genau das lesen und schreiben von Variablen und das aufrufen von methoden, von der Klasse.

Wenn ich das richtig verstanden habe, kann TReader und TWriter die VMT daten einer Klasse auswerten oder liege ich da falsch ?
Weil meine TXD_RTTI Variante ja nur ein speziellen Teil der VMT Daten auswerten kann und wir mit den 3 Klassen schon ein bugfreies und schon in der RTL vorhandenen Sache zu tun hätten.

Edit:
Mein TXD_RTTI ist nach der über mir aufgeführten Funktionalität eigentlich eine abgespeckte TComponent.
Denn ich nutzte ebenfalls TPersistant, um an die RTTI daten der Klasse zu kommen.
Wer sich mal TXD_RTTI genauer angucken will, kann hier http://www.linuxprofessionals.org/xdream/wiki/index.php/XD_RTTI was zu finden.

Edit2:
Ich hab mir nun TComponent und TWriter und TReader angeguckt und muss sagen, dass es sich stark ähnelt mit dem was ich gemacht habe aber meine Variante ist wesentlich einfacher zu nutzen und übersichtlicher.
Wir würden mit TComponent verdammt viel Metacode erstellen müssen um unser Ziel zu erreichen.

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

Projekte: https://github.com/tak2004

Das steht in der Delphi Hilfe über TWriter:


Hier lassen sie sich nicht detailliert darüber aus, was er wirklich macht. Aber nach einem kurzen Blick in die Unit Classes würde ich sagen: er schreibt wohl alles, was gebraucht wird, um eine Klasse wiederherzustellen (Klassenhierarchie/KlassenID/Klassenname/Klassenstruktur/Inhalt der Felder) in den Stream, ein TReader liest die Daten aus dem Stream und stellt sie wieder her. Sollte meiner Meinung nach so funktionieren. Sicher wird er wohl Infos aus der VMT brauchen, aber er braucht auch noch mehr.

@edit: Er müsste auch die Objekthierarchie in den Stream schreiben, TGUIItem wird höchstwahrscheinlich nicht nur Descendants der ersten, sondern auch der zweiten und dritten Generation haben.

@edit2: Ich sehr mir Deine TXD_RTTI an, aber erst morgen. Heut ist immerhin Samstag abend. Ein Bier wartet auf mich.
Traude

Hallo,
@ Tak: Ich habe mir Dein TXD_RTTI angesehen. Im Prinzip stellst Du mit diesem Ding Informationen über ein Objekt bereit: die Variablen und die Methoden, beschreibst die Methoden und ihre Parameter, knapp und übersichtlich.

Ich wollte nun eigentlich zum Vergleich wissen, wie Delphi das macht. Ich habe mir zunächst nochmal TPersistent angesehen, das stellt Lade- und Speicher-Infos zur Verfügung. Irgendwie muss das Ding ja an seine Informationen kommen. Die Delphi Hilfe gibt zum TPersistent nicht allzuviel her. Sie spuckt erst unter dem Stichwort "Classinfo" Informationen aus:



Und wirklich befindet sich in der Unit Classes folgender Code:



Zu Compilerdirektiven wird immer auf die Delphi-Hilfe verwiesen. Dort bin ich nicht fündig geworden, erst im HTML-Hilfe-File zu Free Pascal, Programmer's Manual, Compiler Drectives:




Anmerkung von mir: Delphi machts genauso: die Unit TypInfo ist in Delphi in \DelphiVerzeichnis\Program\Source\Rtl\Common zu finden. Die Prozeduren in der Unit TypInfo sind reichlich verschachtelt und kompliziert.

Das heißt: wenn man seine Objekte von TPersistent ableitet, wird dazu Klasseninformation bereitgestellt (man kann natülich auch sein eigenes Objekt mit $M+ kompilieren). Daher kennen auch alle TComponents, die von TPersistent abgeleitet sind, ihre Klasseninformationen bestens, im Unterschied zu gewöhnlichen TObjects. Das ist ein Aspekt von TComponent, der mir bisher nicht bewusst war. Was sagt Ihr dazu?

@Tak: Du machst es ja auch über TPersistent. Also musst Du Deine Infos aus der gleichen Quelle haben.

Traude

Wo ich die infos her habe, steht auch im Link den ich oben gepostet habe.
Ich hab im X-Dream Wiki die Kompo erklärt und am anfang ist ein Link, zu einem Artikel, der erklärt wie die Klasseninfos gespeichert werden und wie man darauf zugreifen kann.
Hier ist nochmal der Link http://www.linuxprofessionals.org/xdream/wiki/index.php/RTTI aber der Artikel ist nicht fertig und deswegen steht am ende nichts zu der API von TypeInfo.

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

Projekte: https://github.com/tak2004