DFMEdit

[_frank_]

Hi,
ich wollte dieses Forum mal nutzen um meinen DFM-Editor bekannt zu machen.
Wer möchte, kann diesen ja mal testen, Sourcecode/Binaries liegen bei sourceforge.
Grundphilosophie ist Unterstützung aller delphi-versionen, somit kein automatisches Hinzufügen von Eigenschaften.
Vorschau, Eigenschaften-Enumeration und viele andere Sachen sind bereits integriert.
Ich verwende ihn auf einer USB-Variante von Delphi, die keine Installation voraussetzt.

http://dfmedit.sf.net (Projektseite von Sourceforge, dort sind auch einige Screenshots zu finden)
http://www.fw-web.de/dfmedit_beta.php (betas, die vcl30.dpl kann hier runtergeladen werden!)

letzte beta (Direktlink):
mit Laufzeitpackage-Support (benötigt VCL30.dpl):
dfmedit_0.3.0.4b.zip
ohne Laufzeit-packages:
dfmedit_0.3.0.4b_nopackage.zip
source:
dfmedit_0.3.0.4b_src.zip

Hoffe auf viel Feedback.

Gruß Frank

[uligerhardt]

Zitat von _frank_:

zu dem TBitmap...use the source luke
ich nehm mir ein TImage, weise diesem ein temporäres Bitmap zu (um eine Eigenschaft Bitmap.data zu erstellen), generieren ein DFM, ersetze die bilddaten und schreibe das dfm zurück. Eine bessere Möglichkeit ist mir noch nicht eingefallen. GGf. füge ich den TPicture-Header an oder lösche diesen beim schreiben des treenodes. Das geht natürlich nur bei Grafiktypen, die von TImage (bzw. TGraphic) unterstützt werden.

Hast du schon mal geschaut, was in TGraphic.DefineProperties abgeht? (Keine Ahnung, ob das jetzt besonders gut zum Thema passt. )

Uli.

[uligerhardt]

Zitat von _frank_:

Binärproperites [...] würde ich aus der funktion rausnehmen

Noch ein Schuss ins Blaue: Vielleicht könnte man da passende Ressourcendateien generieren? Z.B. kannst du ja eh schon ein Bitmap laden, um es anzuzeigen. Dann sollte ja auch dessen Speichern kein Problem sein, z.B. unter einem Dateinamen, dern du aus der Owner-Hierarchie bastelst, und als Quellcode erzeugst du statt einer Property-Zuweisung eine LoadFromResource oder so.

[_frank_]

Hi,
Für Resourcendateien braucht auch einen resourcencompiler...somit bleibt nur die Möglichkeit Datendatei+optionale *.rc

also das mit der Bitmap-Zuweisung zu verwenden halte ich für keine gute Idee. Ich kann nur einen bruchteil der möglichen binärdaten laden und ein temporäre TImage zu erstellen nur um ein Bitmap zu laden...da wär es mir lieber wenn mir jemand sagen kann, wie ich die dfm-daten direkt dekodieren kann um diese zu speichern.
Es sind eigentlich nur hex-werte und bitmaps gehen bekanntlich mit "42 4D" los, ich kann bei bitmaps auch gleich ab dem "Header" in eine Datei schreiben. aber bei anderen Dateitypen geht das nicht (der header von anderen Typen ist imho nicht statisch).
Wenn mir jemand sagen kann, wie ich andere Typen in ein dateiformat bekomme, kann ich sowas implementieren bzw. ich kann es erstmal nur für TBitmap implementieren, wenn der Header von TBitmap erkannt wird. Die anderen formate habe trotz mehreren Versuchen nicht hinbekommen (z.B. ico, dib).

Man kann zwar davon ausgehen, dass der TPicture-header (bei TBitmap) folgendermaßen aussieht:
byte 1: länge des enthaltenen Klassennamens (z.B. 07 für TBitmap)
byte 2-x: der klassenname (TBitmap => 54 42 69 74 6D 61 70)
4 variable bytes (die ich noch nicht entschlüsselt habe, wird irgendwie aus größe und farbpalette generiert)
dann das bitmap selbst

bei TIcon fehlen die 4 variablen bytes so dass nur die länge und der klassenname als TPicture-Header drinstehen.

was aber wenn der header fehlt bzw. es sich nicht um bitmap oder ico handelt (z.B. delphiX benutzt Binärfelder zum speichern der Tastenzuweisungen und für dibs)?

Wie ihr seht ist diese Sache nicht ganz ohne ;(

Zitat von uligerhardt:

Hast du schon mal geschaut, was in TGraphic.DefineProperties abgeht? (Keine Ahnung, ob das jetzt besonders gut zum Thema passt.

da bin ich nicht zu dem punkt gekommen, die daten zu importieren... Wenn es Jemand weis, kann ers mir gerne verraten. Imho kann man mit defineProperties nur eigene handler registrieren, welche die daten verwerten. Aber vorhandene mit diesen daten aufzurufen ist mir noch nicht geglückt

Gruß Frank

[rider]

Hallo Frank,
hab' mir dein Tool angesehen und es gefällt mir sehr gut!

Ich hätte einen Vorschlag für ein sehr nützliches Feature:
Automatisches Entfernen überflüssiger Properties.

BDS 2006 und Turbo Delphi haben die unangenehme Eigenschaft, dass einige überflüssige Properties in der DFM Datei gespeichert werden.
Das sind ExplicitLeft, ExplicitTop, ExplicitHeight, ExplicitWidth.
Für eine nähere Erläuterung:
http://jedqc.blogspot.com/2006_02_01_jedqc_archive.html

Zusätzlich gibt es schon seit längerem ein DesignSize property in der DFM Datei. Auch das hat keinen Einfluss auf das lauffähige Programm.
http://bdnqc.borland.com/wc/qcmain.aspx?d=1646

Bei ToolButtons mit Style tbsSeparator werden die Properties Caption und ImageIndex gespeichert, die in diesem Fall überhaupt keinen Sinn ergeben.

(Wahrscheinlich gibt es auch noch andere überflüssige Properties in der DFM Datei.)

Das sind Properties, die gar keinen oder nur im Delphi Designer einen Sinn machen - und auch da nur begrenzt.
Leider werden diese Properties in der DFM Datei gespeichert und blähen so unnötig das Programm auf.


Es wäre also sehr nützlich, wenn ein Tool diese Properties automatisch entfernen könnte.

Meinst du, das würde sich realisieren lassen

[_frank_]

Hi,
die ersten beiden wären imho relativ leicht realisierbar (wenn diese bedingungslos gelöscht werden sollen, hab ich das richtig verstanden?).
bei den Toolbuttons ist das schon mehr Arbeit, da diese Bedingungen erfordern, die ich ungern hardcoded machen möchte (somit parsen der bedingung und anwenden dieser nötig).
das Löschen von properties allgemein müsste in einer konfigurationsdatei inkl. bedingung definiert werden, da dfmedit nicht erkennen kann was "unnötig" ist...
Ich bin grade dabei, die Geschichte mit der Laufzeit-Code-Generierung zu realisieren (klappt auch schon ganz gut ohne spezialeigenschaften ). hatte die letzten Tage wenig Zeit...

wäre schön, wenn sich noch ein paar Tester finden würden, die die Sache mit dem multiselect testen würden.

Gruß Frank

[rider]

Zitat von _frank_:

die ersten beiden wären imho relativ leicht realisierbar (wenn diese bedingungslos gelöscht werden sollen, hab ich das richtig verstanden?).

Ja, die sollen einfach gelöscht werden. Vor allem bei komplexeren Formularen mit Frames und PageControls wird die DFM Datei geradezu übersät mit Explicit* Properties.

Zitat von _frank_:

bei den Toolbuttons ist das schon mehr Arbeit, da diese Bedingungen erfordern, die ich ungern hardcoded machen möchte (somit parsen der bedingung und anwenden dieser nötig).

Verstehe. Die Bedingung wäre allerdings recht einfach:
object <name>: TToolButton, Style = tbsSeparator
Properties ImageIndex und Caption löschen.

Mir ist inzwischen noch ein überflüssiges Property eingefallen:
object <name>: TToolBar, DragKind = dkDrag
Property Caption löschen.

Zitat von _frank_:

das Löschen von properties allgemein müsste in einer konfigurationsdatei inkl. bedingung definiert werden, da dfmedit nicht erkennen kann was "unnötig" ist...

Das wäre natürlich große Klasse, wenn sich das konfigurieren ließe. Es finden sich bestimmt noch weitere überflüssige Properties.

Ich könnte mir vorstellen, dass so ein "DFM Optimizer" bestimmt großen Anklang in der Delphi community finden würde.

[_frank_]

hier mal eine Vorab-Version von DFMEdit mit automatischer Code-generierung (IntList+Binär wird noch nicht unterstützt, Rest sollte funktionieren)...einen Objektknoten markieren und den button auf dem DebugPanel verwenden. Die Ausgabe ist im Ausgabe-Memo zu sehen.

Das mit dem automatischen Löschen hab ich auch eingebaut...der 2. Button auf dem debug-panel
Es wird die unwanted.obj verwendet (kurze Erklärungen in der Datei).

DFMedit mit _debugmode.bat starten, um das debugPanel anzeigen zu lassen

beide routinen müssen ggf. noch optimiert werden, haben aber in meinen Tests super funktioniert

Ist alles wie gewünscht?

//edit: attachments gelöscht

Gruß Frank

[DevilsCamp]

Ich finde es wäre nett, wenn du zwei Versionen machen könntest:
Eine, so wie jetzt

und Eine mit EINGEBUNDENER VCL30.BPL. Da ich kein Delphi 3 besitze, wird das starten ohne diese Datei etwas schwierig...

[uligerhardt]

Zitat von DevilsCamp:

Ich finde es wäre nett, wenn du zwei Versionen machen könntest:
Eine, so wie jetzt

und Eine mit EINGEBUNDENER VCL30.BPL. Da ich kein Delphi 3 besitze, wird das starten ohne diese Datei etwas schwierig...

Kompilier's halt selber. Ich hab den Quellcode problemlos mit Delphi2006 übersetzen können. Das werde ich gleich noch mit der neuesten Version probieren.

Uli.

[_frank_]

das mit der dpl hat den sinn, dass man auch zur laufzeit belibige pakete mit komponenten hinzufügen kann...dies funktioniert nicht, wenn die dpl statisch in die exe gelinkt ist.
Hab die datei oben angefügt...

//edit:
bei den stable-versionen wird die datei mit ins Archiv gepackt, bei den betas verkneife ich mir das, da sich an der Datei nix ändert und es nur sinnlosen traffic für mich und andere bedeutet...

Gruß Frank