Wie am elegantesten eine eigene IDE "basteln"

[stahli]

Das Problem mit dem Verwenden des "Geräte-Projektes" unter "Windows" wird sein, dass Deine "Geräte-Controls" wohl nichts mit einem VCL-Control zu tun haben (würde ich mal voraus setzen).

Aber Deine Gerätesoftware muss ja dennoch erkennen, dass z.B. ein Button gedrückt wurde. Vielleicht kannst Du mal noch was sagen, wie Du dieses Gerät programmierst.

Wenn Du für die IDE etwas neues baust und TGraphicControls verwenden willst, dann würde ich für erste Tests abstrakter denken.
Wenn Du in Buttons, Labels, Checkboxen usw denkst, könnte das leicht zu gedanklichen Verwirrungen führen.
Ich würde einfach mal andenken, beliebige Objekte (Früchte, Autos und Zettel) zu verwalten und darzustellen und deren Eigenschaften zu verwalten.

Du brauchst ja in der IDE keinen wirklichen TButton sondern nur einen Platzhalter, dem bestimmte Eigenschaften zugewiesen werden.
Wenn Du einem Button eine "Ereignisbehandlung" zuweist, ist das ja auch nur irgendein blöder Text, mit dem die IDE letztlich nichts anfangen kann.

[hedie]

Zitat von stahli:

Das Problem mit dem Verwenden des "Geräte-Projektes" unter "Windows" wird sein, dass Deine "Geräte-Controls" wohl nichts mit einem VCL-Control zu tun haben (würde ich mal voraus setzen).

Aber Deine Gerätesoftware muss ja dennoch erkennen, dass z.B. ein Button gedrückt wurde. Vielleicht kannst Du mal noch was sagen, wie Du dieses Gerät programmierst.

Wenn Du für die IDE etwas neues baust und TGraphicControls verwenden willst, dann würde ich für erste Tests abstrakter denken.
Wenn Du in Buttons, Labels, Checkboxen usw denkst, könnte das leicht zu gedanklichen Verwirrungen führen.
Ich würde einfach mal andenken, beliebige Objekte (Früchte, Autos und Zettel) zu verwalten und darzustellen und deren Eigenschaften zu verwalten.

Du brauchst ja in der IDE keinen wirklichen TButton sondern nur einen Platzhalter, dem bestimmte Eigenschaften zugewiesen werden.
Wenn Du einem Button eine "Ereignisbehandlung" zuweist, ist das ja auch nur irgendein blöder Text, mit dem die IDE letztlich nichts anfangen kann.

Du hast recht, grundsätzlich soll in der IDE ein Platzhalter angezeigt werden, welcher die grösse des objekts auf dem Display hat. Theoretisch würde dazu ein TShape genügen. Dieses könnte dann halt einfach nicht die entsprechenden Farben darstellen. Diese müsste mann dann über den Objektinspektor ändern. Für den Anfang jedoch ausreichend.

Nun etwas zur Gerätesoftware und Hardware:

Es befindet sich ein STM32 Cortex M3 (32Bit Mikrocontroller) auf dem Board.
Dieser steuert den Displaycontroller direkt an. Damit kann er jedes einzelne Pixel setzen.
Meine Firmware ist in C geschrieben. das sogenannte uGUI (mikroGUI) kennt verschiedene Controls.
Unter anderem einen Button.

Wenn nun ein Button erstellt wird, so werden zwei Strukte erstellt.
Das eine beinhaltet die x0,y0,x1,y1 sowie einen pointer zum eigenschaften strukt sowie einen pointer zur "onClick" funktion.

Wenn nun jemand auf den Button drückt, so wird ein Intterupt im Controller ausgelöst.
Sobald dieser eingetroffen ist, wird die x,y position des Touchscreens ausgelesen.

Nun geht das programm in einer schleife alle strukte mit den koordinaten durch und prüft ob sich
die touch koordinaten x,y, innerhalb eines objekts befinden.

Wenn dies der fall ist, wird die darin definierte "onClick" funktion aufgerufen.


Bisher wird die erzeugung des GUIs "hardkodiert". Daher die funktionien CreateButton etc.
werden direkt im Programmcode aufgerufen, compiliert, und in den Controller geladen.
Änderungen sind dann nicht mehr möglich.

Mein ziel ist es, auf der Hardware, also im Controller, einen Python interpreter laufen zu lassen.
Damit könnte mann dann später buttons dynamisch mittels skript erzeugen lassen.
Steht dann im Python skript CreateButton... dann wid intern in der Firmware einfach ebenfalls CreateButton mit den entsprechenden Parametern aus dem Python skript aufgerufen.

Damit die erzeugung eines GUIs für den Endanwender so bequem wie möglich wird, möchte ich nun einen grafischen editor für das GUI erstellen.
Beim Platzieren eines Buttons bzw. eines Platzhalters dafür soll im hintergrund bzw, im Codefenster
sogleich der dazugehörige Pythoncode erstellt werden.

Dieses Pythonskript wird dann später auf einer SD-Karte abgelegt und vom Controller ausgelesen.

[himitsu]

Man könnte auch die normalen Windows/Delphi-Controls benutzen.

Man kann die "unsichtbare" Form ja regelmäßig auf ein Bitmap zeichnen und Dieses zum Display übertragen.
Befehle vom Display kann man über Messages an das Form zurückgeben.

[hedie]

Zitat von himitsu:

Man könnte auch die normalen Windows/Delphi-Controls benutzen.

Man kann die "unsichtbare" Form ja regelmäßig auf ein Bitmap zeichnen und Dieses zum Display übertragen.
Befehle vom Display kann man über Messages an das Form zurückgeben.

Danke für deinen Input.
Eventuell ist dies ein wenig untergegangen... Das Display stellt eine eigenständige Einheit dar.
Dieses wird unabhängig vom Computer verwendet.

Die "IDE" soll nur dazu dienen, dem Anwender das Skripten zu erleichtern.

[himitsu]

Ohh, na dann nicht.

Man kann DFMs auch manuell auslesen TReader und falls als Text-DFM gespeichert, vorher ObjectTextToBinary.
Man kann da auf Seite des Designers auch mit anderen Komponenten arbeiten, wie im Display.
TGraphicControl-Nachfahren im Designer und beim Display bentutzt man irgendwas für dessen ansteuerung ... solange die Properties übereinstimmen ist es ein gängiges Verfahren, wenn zwischen Designtime-Komponenten und Runtime-Komponenten unterschieden wird.
Die müssen nur den gleichen Namen besitzen, oder einen Alias, und brauchen die selben Property (die Runtimekomponente muß mindestens das unterstützem, was die Designtimekomponente bereitstellt)

So kannst du fertige Designer und deren Serialisierung benutzen und mußt hier nichts selber bauen.
Nur die nötigen Runtimekomponenten bauen (oder von vorhandenen Ableiten). Wenn man Runtime auch auf ein Bitmap zeichnen kann, dann können die direkt verwenden.

z.B. im Designer TMyDisplayEdit von TCustomEdit ableiten, dort nur das nach Published verschieben, was man braucht und dann ein weiteres TMyDisplayEdit für den Displaycode.

[BUG]

Ich würde es für eine merkwürdige Designentscheidung halten, DFMs für das Speichern der Formulare zu verwenden

Deine Runtime (und alle anderen Anwendungen, die eventuell mit den Formular-Dateien umgehen) müssen einen DFM-Parser implementieren ... und das nur, weil die IDE in Delphi implementiert wurde.
Ich denke mit einem standardisierten Format bist du besser dran.