@Lars: Das habe ich mir auch schon einmal überlegt. Allerdings habe ich davon Abstand genommen, da die TComponent mir für meine Componenten ein wenig zu viel mitschleppt. Ich habe die Komponenten auf TPersistent aufgebaut um Sinnvoll auf die Properties zugreifen zu können. Und ehrlich gesagt sehen ich so auch nicht die Notwendigkeit warum das mit der VCL kompatibel sein muss.
Ein Argument lasse ich noch gelten. Derzeit wrden ja alle Properties direkt im Quellcode gesetzt. Da werde ich mir früher oder später noch etwas einfallen lassen. Auf was genau es hinaus läuft weiß ich noch nicht. Zumal ich auch bedenken muss, dass dies mit dem ScriptCompiler kompatibel sein muss. Und das ist ein nicht zu unterschätzendes Problem. Aber abwarten und Tee trinken.

Ich dachte daran, daß es für die zukünftigen Benutzer eventuell leichter ist, wenn das ganze System so wie in Delphi aufgebaut ist. Nicht weil man dann Delphi Formen konvertieren könnte, sondern weil das die Akzeptanz der Komponentensammlung auch bei unerfahreren Programmierern erhöhen könnte, denn die VCL ist ja faktisch das erst was man kennen lernt. Eine ähnliche Idee steckt ja auch hinter der VCL .Net. Die ist ja nicht besser, weil einige Properties anders heißen oder so, sondern weil man bestehendes Wissen weiterbenutzen kann.
Für ein Spiel oder eine Engine ist das, auch aus meiner Sicht, sicherlich zu viel Aufwand der sich für einen selbst nicht unbedingt auszahlt. Da lohnt es sich, daß eher einfach und funktional zu halten, aber ihr wollt doch eine universelle Komponentensammlung bei der sich das doch eigentlich lohnen würde.

Also von den Enthaltenen Componenten her klingt das schon doll! Jetzt ist nur noch die Frage wie ich das einbauen kann. Wenn du irgendwann mal Testversion hochstellst werd ich die mir mal angucken. Für mein Momentanes Projekt (Einen Sportmanager ) hab ich gezwungenermaßen sowas im Ansatz selber machen müssen und da merkt man dann halt im Verlauf des Codens was man am Anfang alles net bedacht hat. Deshalb würde sowas wie ne gut durchdachte Componentensammlung in ner Unit, die man nur noch einbinden muss und fertig, schon eine Echte Hilfe darstellen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

@Flash: Also ich könnte für private Testzwecke recht schnell meinen aktuellen Stand mal hochladen. Allerdings ist der Mega instabil und teilweise ist dort nur die Hälfte implementiert. Aber zum Antesten sollte das schon genügen. Mal schauen wann ich dazu komme.

@Lars: Es wäre natürlich Ideal, wenn das so aufgebaut wäre wie die VCL. Also oben lediglich die gesammten Objekte definiert und die gesammten Einstellungen und Methoden werden dann aus einer dfm (die in die Resource mit eingebunden ist) geladen. Allerdings hat das ein paar Probleme.
- Klassen können in dem Pascal Script selbst NICHT definiert werden. (Was ich persönlich auch als äußerst schade empfinde)
- Die Resource müsste ich irgendwie simulieren, da ich die Resourcen nun mal so nicht direkt habe.
- Ob es bei den Events Schwierigkeiten gibt kann ich auch nicht ausschließen, da die Klassen nun mal mit Methoden verknüpft werden müssten die in dem Script definiert wären und die Klassen nun mal im richtigen Delphi erzeugt werden.
- Ich habe nicht nur eine Oberkomponente (TForm). Ich habe es so umgebaut, dass dies nicht mehr notwendig ist. Rein theoretisch könnten sich alle Komponeten auf der obersten Ebene befinden.
- Das Formular wird von der Application erstellt und dort wird dann auch das Laden der Eigenschaften angeworfen.
- Ich habe meine Komponenten so aufgebaut, dass sie nur ab einer gewissen Basisklasse (TglWinControl) auch tatsächlich Unterkomponenten besitzen können. Dem wäre dann nicht so. Das ließe sich aber zur Not auch noch irgendwie verhindern.

PS: Eigentlich war das auch nur für ein Spiel gedacht. Das es so großes Interesse mit sich zieht hätte ich nicht gedacht. Dadurch wird das jetzt alles auch schon wieder sehr groß. Aber nun habe ich damit angefangen jetzt mache ich es auch so, dass man damit vernünftig arbeiten kann. Fehlende Features und Bugfixes kann man ja immer noch machen.

Ich habe schon mal mit em Gedanken gespielt, dass die Komponenten erzeugt werden und alle Eigenschaften anhand eines Namens aus einer XML-Datei geladen werden. Die Events würden dann wieder ganz normal im Code stehen. Das würde die Sache auf jeden Fall schon mal Verbessern und wäre auch nicht so kompliziert zu implementieren.

Da meine Zeit ein wenig begrenzt ist muss ich aber auch gestehen, dass die VCL Variante in meiner Priorität recht weit unten angesiedelt ist. Ich muss auch sagen, dass dies größtenteils nur eine "Spielerei" für den Entwickler ist. Für den Benutzer spielt es keine Rolle, ob das aus einem Text, einer Resource kommt oder ob es direkt in den Quellen drinne steht. Viel wichtiger sind für mich derzeit einfach die Implementierung von Features im Editor und in den Komponenten.

Der neue Form Designer kann sich schon sehen lassen. Mir sind eigentlich nur zwei kleinere "Fehler" aufgefallen:
1.) Die Eigenschaften werden nicht sofort aktualisiert,sondern erst wenn man zu einer anderen Eigenschaft wechselt.
2.)Es gibt eine "Assertion fehlgeschlagen" Fehler wenn man das Texture Rect bearbeiten will.

Ansonsten könntest du ja vor jeden Block mit generiertem Code noch einen Kommentar mit dem Namen setzen, wie das im C# Builder ist.

Gut gefallen hat mir die Möglichkeit das der Programmcode direkt ausgeführt wird, so wie das auch beim C#Builder und beim JBuilder ist.
Ich weiß nicht wie schwer es ist, auf- und zuklappbare Bereiche bei Synedit einzufügen. Das wäre vielleicht auch noch eine gute Idee.
Schön wäre auch noch, wenn die Formulare eigene Klassen wie bei Delphi wären, aber das liegt vermutlich an dem Innerfuse Script. Aber das sind alles nur kleinere Dinge, isgesammt macht das Programm einen recht ausgereiften Eindruck.

Zum Thema Eigenschaften. Die werden geändert sobald du Enter drückst oder auf ein anderes wechselst. Ist in Delphi auch so. Sofortiges ändern finde ich nicht so gut, wenn man sich zum Beispiel vertippt. Ungültige Werte, zu viel Quellcodeparserrei etc.

Das mit dem Assert okay das ist schwachsinnig. Du hast bestimmt das Bild Editieren wollen, oder? Das ist das einzigste ohne AlphaKanal. Das Muss ich noch implementieren. Der RectEditor kann derzeit leider nur mit Alphakanal. Sollte ich mal machen bevor ich das vergesse.

Das mit dem Auf und zu klappen ist eine gute Idee. Muss ich aber mal schauen wie sich das damit überhaupt realisieren ließe. Und vor allem ist dabei die Zeit nicht ganz unwichtig.

Klassen würde ich selber ja auch gerne haben. Nur leider kann das dieses ... Pascal Script nicht. Habe ich leider auch erst sehr spät mitbekommen. Deswegen auch die Idee mit dem richtigen Delphikompiler. Allerdings hackt es da noch ein wenig in den Details.

Ja die Zeit ist immer der größte Feind...

Die Sache mit der Änderung bezog sich auf Listen. Wenn man da einen neuen Wert auswählt ist es schon schöner wenn man das Ergebis gleich sieht. Bei Edit Felder ist es klar.

Achso. Okay. Das werde ich auch ändern.

Wie willst du das denn eigentlich mit den Code Änderungen machen, wenn du den Delphi Compiler verwendest? Erstellst du dann eine DLL oder wie ist das vorgesehen?

So hatte ich das auch angedacht. Da muss ich allerdings erst einmal testen ob das überhaupt funktioniert. Also ich schicke meine Quellen an den Compiler mit einem vordefiniertem Programm und dieser erstellt mir eine DLL. Diese lade ich dann und rufe die entsprechenden Methoden auf. In diesen Methoden zeichne ich dann meine Elemente. Evtl kann es mir dann sogar passieren, dass ich die OpenGL Initialisierung aus der DLL heraus machen muss. Das wird sich beim Testen allerdings herausstellen.
Dan habe ich allerdings das Problem, dass das umschalten zwischen Source und OpenGL noch länger dauert. Aber da finde ich schon ne Möglichkeit. Wenn nicht mache ich ein kleines Spiel so wie bei WinOnCD 5.

Was passt dir denn an Pascal Script nicht? Dass man keinen neuen Klassen erstellen kann?

Das klappt gar nicht schlecht, zumal man den Ort der verschiedenen Delphiversionen leicht aus der Registry rauslesen kann (= keine Konfiguration durch Benutzer notwendig). Wenn's dich interessiert, kannst du eventuell die neueste Version von BGP ansehen (http://www.basegraph.com/bg/instpack/bgp.zip), dort gibt es genau das als Option - ich bin übrigens mit uPS recht zufrieden, erlaubt es doch Code mit wenigen Änderungen, die sich zudem noch automatisiert im Programm einpflegen lassen, direkt in Delphi zu kompilieren.

Ansonsten scheint mir Lars Pascal Compiler recht interessant zu sein, mit dem man bestehende Delphiklassen direkt um Funktionalität erweitern kann, die noch dazu "echt" kompiliert wird, leider habe ich selbst noch nichts damit gemacht.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Du wirst lachen. Die aktuelle Version von BGP hat mich erst auf diese Idee gebracht. Aber auf diese Version werde ich dankend zurück kommen.

Und was mich daran stört ist recht einfach. Man kann nur das verwenden was ich vorher an Funktionen und Klassen definiert habe. Eigene Klassen und Units sind somit absolut unmöglich. Man kann selber keine Klassen im Code erstellen. Und ich muss per Hand vor dem Kompilieren, die Uses und Implementation herausschneiden, da es sich sonst nicht kompilieren lässt. Und da das nun mal eine Art IDE darstellen soll sind solche Beschränkungen ziemlich doof.

Das beste wäre natürlich man könnte ein bereits implementiertes fenster noch einmal editieren und so etwas. Ohne, dass sich das on dem ganzen drumherum stört. Aber das wäre ein wenig zu viel des Guten.

Wäre es nicht ohnehin umständlich, neue Klassen zu erstellen? Der Formulardesigner erstellt ja auch nur eine einzige Klasse - einen TForm Descendenten - der dann die ganzen Controls und deren Eventhandler enthält, welche den Controls erst während deren Instanziierung zugeweisen werden (OnClick eines TButton ist z.B. keine echte Methode, sondern nur ein Zeiger auf eine Funktion, die zur Laufzeit zugewiesen wird - das geht aber sogar innerhalb von uPS, da Funktionszeiger unterstützt werden).

An sich sollte es doch nicht allzu umständlich sein, die generierte Unit im Programm folgendermaßen aufzubereiten:

Spezielle Kommandos, die für das Utility wichtig sind, stehen z.B. hinter //<, dann erkennst du sie sofort, und brauchst keinen besonders komplexen Parser - Visual Studio macht dies z.B. genau so (wenn man dort dann was ändert, schaut die automatische Codegenerierung ebenfalls blöd drein), eine so intelligente Verwaltung wie Delphi, das ganz ohne Metatags auskommt, brauchst du ja nicht

Du hast ein Panel (entspricht einem Formular in Delphi) und einen Button darauf, dem eine OnClick Routine zugewiesen wird.
Die generierte Unit könnte folgendermaßen aussehen:



der generierte PS Code sieht dann folgendermaßen aus (. wird einfach durch _ ersetzt, der Unterstrich kann in deinem Projekt ruhig ein reserviertes Zeichen sein (also nicht in Namen verwendet werden dürfen) ).
Self. wird innerhalb einer Methode einfach durch den Klassennamen und einen Unterstrich ersetzt - auch dafür muss der Parser nicht besonders intelligent sein:



Diesen Code kannst du dann einfach ein ein PS Projekt kopieren (oder noch einfacher per $include einbinden), und an gegebener Stelle aufrufen (im Prinzip müssen eigentlich nur die aus den Konstruktoren generierten Routinen aufgerufen werden, nachdem die den TPanel Klassen (oder was immer du als "Hauptformulare" haben möchtest) entsprechenden Variablen instanziiert wurden.
Auch mehrere Panels in einer Unit machen kein Problem, da deren Eigenschaften durch die Namenspräfixe in uPS sauber voneinander abgetrennt sind, in Delphi hast du hingegen schöne Klassen, ähnlich wie sie der Formulardesigner selbst erstellt.

-----------------

Der Formulardesigner schaut übrigens toll aus - hättest du prinzipiell etwas dagegen, wenn ich eine etwas angepasste Version in BGP einbauen würde (hauptsächlich auf meine eigene Texturverwaltung umgestellt).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ja gut. Klassen könnte man mit dieser gut ausschauenden Methode schon recht leich simulieren. Allerdings streube ich mich persönlich etwas dagegen, da 1. der Code dadurch nicht unbedingt einfacher wird. und 2. es dennoch nur ein "dahinbiegen" bleibt. Und das ist keine Sache die ich gerne tue.
Das weitere was mich daran noch masiv stört sind:
- Keine Möglichkeit andere Units einzubinden
- Keine überladenen Methoden möglich
- Keine Defaultparameter Möglich
- Sehr große Fehleranfälligkeit, sollte nicht alles 100%tig genau definiert worden sein
- Und die Geschwindigkeit ist nicht so die Beste.

Fenster gibt es bei meinem glComponents so direkt nicht. Das könnte man allerdings noch recht einfach erstellen. Der Grund warum ich dafür ein Panel verwende ist nur der, weil es eine Textur beinhaltet und Unterobjekte besitzen kann. Dies kann neben dem Panel nur noch das WinControl. Dies ist aber eine unsichtbare Komponente. Und sichtbar seht doch einfach schöner aus.

Prinzipiell sehe ich da von meiner Seite aus keine Einwände. Also das du den Designer verwendest.

Ach ja - die Krux des (guten) Programmierers: nicht nur funktionieren soll es, auch ästhetisch muss es sein .

Etwas OT möchte ich hier dennoch hinzufügen, dass im Prinzip die ersten C++ "Kompiler" genau so gearbeitet haben (soll heißen, sie haben über Präprozessoren Ansi C Code erstellt, der dann erst wirklich in Maschinencode umgewandelt wurde). Überladene Routinen erhalten auch heute noch beim Linken eindeutige Namen (meist indem einfach die Stackgröße drangehängt wird wird), um eindeutige Aufrufe zu erhalten. Selbiges gilt für Defaultparameter, die einfach bereits beim Kompilieren automatisch eingefügt werden - der langen Rede kurzer Sinn: existierende "echte" Kompiler machen's auch nicht besser (immerhin - im Falle von Delphi - in einem einzigen Durchgang) - allerdings macht es in meinen Augen durchaus Sinn, direkt den Delphi Kompiler zum Testen zu verwenden, zumal der erstellte Code dann auch in Delphi funktionieren soll.

___________________________

dann bedanke ich mich recht herzlich, und werde mir den Code des Designers genauer ansehen. Im Gegensatz zu dir werde ich allerdings bei einem prozeduralen Ansatz bleiben, da ich Oberflächen direkt in PS haben möchte, das dann über das BGP Framework ja ohnehin auch als Delphi Projekt kompiliert werden kann (Units kann man übrigens recht gut über include Dateien "simulieren").
Sollte ich zu einem brauchbaren Ergebnis kommen, lasse ich es dich auf jeden Fall wissen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/