DFMEdit

[_frank_]

hi,
neue Hauptversion (0.2) ist offiziell *push*
nach diversen Beta-Versionen ist nun endlich wieder eine "stable"-Version offiziell.
leider konnte ich noch kein Multiselect implementieren, da die neue Version der Sizing-Komponente noch einige störende Eigenschaften hat, aber im vergleich zu der letzten Stable wurden viele Funktionen hinzugefügt und Fehler beseitigt.
Falls trotzdem Fehler auftreten sollten, bitte mir mitteilen.

( http://dfmedit.sf.net )

Gruß Frank

[_frank_]

Zitat:

Zitat von Daniel G

Hmm... Sowas wie Multiselection wäre nicht schlecht, quasi so wie "Shift + Linke Maustaste" in der Delphi IDE, weil ich doch auch gerne mal Gruppen verschiebe, dabei aber die Ausrichtung beibehalten möchte..

ich bin grade dabei, das multiselection zu implementieren. funktioniert auch ganz gut, nur Arbeiten im OI und die Copy&Paste werden mit Multiselection noch eine Weile dauern...

ansonsten hier mal eine Version für die die das multiselection haben möchten ;)
weiterhin kann man knoten im Treeview kopieren (Drag&drop+Strg) und mehrere Controls erstellen (z.B. 10 Checkboxen mit automatischer Ausrichtung)

Gruß Frank

[DevilsCamp]

Ich suche die nette Funktion, aus den Daten der dfm-Datei den Quellcode für das erstellen einer Komponente zu erstellen, die er in Post #36 erwähnt wurde.
Ist die nicht mehr enthalten oder finde ich die nur nicht?

[_frank_]

die war in seinem programm enthalten.
Dfmedit bietet momentan nur die Möglichkeit, die unit zu dem formular zu erstellen, wie delphi selbst.

[DevilsCamp]

Kennst du sonst noch ein Programm, dass genau das tut?

[_frank_]

nein, ich kenn kein solches Programm.
sowas könnte ich auch in DFMedit einbauen, da gibt es aber leider einige Sachen, die sich nicht so einfach realisieren lassen (Binärproperties, Listen,...). Weiterhin ist es nicht möglich Parameter im contructor zu berücksichtigen.
Momentan sehe ich noch keinen Nutzen, aus einer DFM-Datei den Quellcode zu generieren.
es gibt Möglichkeiten zur laufzeit DFM-Dateien zu laden (kann man evtl. auch verschlüsseln).

Wozu braucht ihr das?
Evtl. können wir gemeinsam eine solche Funktion für den DFMeditor erstellen.

Gruß Frank

[DevilsCamp]

Zitat:

Zitat von _frank_

Momentan sehe ich noch keinen Nutzen, aus einer DFM-Datei den Quellcode zu generieren.
es gibt Möglichkeiten zur laufzeit DFM-Dateien zu laden (kann man evtl. auch verschlüsseln).

Wozu braucht ihr das?
Evtl. können wir gemeinsam eine solche Funktion für den DFMeditor erstellen.

Gruß Frank

für die Turbo Explorers ;)


Denn wenn eine Komponente in einem Quelltext verwendet wurde, die sich nicht installieren lässt, so muss man diese zur Laufzeit erstellen. Da aber die Informationen in der DFM-Datei liegen, läge es doch nahe, diese zu nutzen damit man die sachen nicht alle selber per Hand eingeben muss.

[_frank_]

wie gesagt, für normale properties (Integer,string,sets,enums,parent-beziehung,events) wäre dies möglich nicht aber für TCollection und binär-Properties.
ich würde diese zeile aber nur objekt-bedingt machen, da ein ganzes form zu erstellen ist evtl. nicht gewünscht. Oder soll das ganze formular in Code generiert werden? Wäre bei der objektbezogener Generierung auch möglich...

Gruß Frank

[DevilsCamp]

Ich denke mal, dass einzelne Objekte erstmal ausreichen dürften (dann muss man halt öfters die Funktion nutzen).




Aber andere Frage:
Wie hast du die Bilddaten eines TBitmaps aus der DFM in ein richtiges Bild umsetzen können?

[_frank_]

die funktion wird auf alle fälle rekursiv sein. d.h. wenn der Form-Knoten verwendet wird, wird das komplette Formular generiert.
ich überlege nur, ob ich bei formuleren nil oder application als owner verwende. siehe dazu http://delphi.about.com/od/adptips20...nilselfapp.htm
Binärproperites und TCollections würde ich aus der funktion rausnehmen, Stringlisten sollten relativ schnell machbar sein.

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. Hinweis, der Tpicture-Header wird in den klammern angezeigt (TBitmap/TIcon/...). Das anzeigen des Headers funktioniert auch bei z.B. TDib (DelphiX), jedoch kann hier das bild nicht angezeigt/bearbeitet werden, da ich hier die codierung noch nicht entschlüsselt habe (normales TDib hab ich noch nicht zum laufen bekommen).

schonmal jemand die multiselect-Variante getestet? Schon Fehler gefunden?
Neuere Funktionen/Bugfixes werde ich nur noch in dieser Version machen.

Gruß Frank

[uligerhardt]

Zitat:

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:

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:

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! :thumb:

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:

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:

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:

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. :idea:

[_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:

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

[DevilsCamp]

Zitat:

Zitat von uligerhardt

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.

Ich bekomme beim starten dann leider folgende Meldung:
---------------------------
Anwendungsfehler
---------------------------
Exception EReadError in Modul rtl100.bpl bei 00037FB3.

Fehler beim Lesen von Edit_SearchText.OnKeyDown: Ungültiger Eigenschaftswert.


---------------------------
OK
---------------------------



Kompiliert habe ich das mit Turbo Delphi Win32

[DevilsCamp]

Bug gefunden:

Wenn ich eine BPL einbinde, so wird diese ein zweites mal in die Liste geschrieben.
Öffne ich das Fenster erneut und klicke nur auf OK, dann erscheinen die Zeile gleich viermal (verdoppelt sich jedesmal).

[uligerhardt]

Zitat:

Zitat von DevilsCamp

Exception EReadError in Modul rtl100.bpl bei 00037FB3.

Fehler beim Lesen von Edit_SearchText.OnKeyDown: Ungültiger Eigenschaftswert.

Das ist schräg. Klingt, als hätte TForm_DFMMain.SearchBoxKeyDown eine zu Edit_SearchText.OnKeyDown inkompatible Signatur, nur hat sich doch an OnKeyDown seit 1731 nichts mehr geändert. Was passiert, wenn du die Form in der IDE aufmachst und speicherst? Mäkelt Delphi dann auch?

[_frank_]

ich hoffe, du hast die vcl30.dpl nur ins Programmverzeichnis kopiert und nicht nochmal separat bei den packages hinzugefügt...

//edit
achso..du versucht es mit TurboDelphi zu kompilieren...mmh, hab das leider nicht drauf, kann dir auch nicht versprechen, dass der code 100%-kompatibel mit turbodelphi ist (wie geschrieben wurde ist der code zumindest kompatibel mit delphi 3-2006)...
zur not die binary nehmen...dpl ist oben (...oder selbst debuggen)
aber den verdopplungs-bug schau ich mir mal an...
//und nochmal edit...warum kommt keine red-box :gruebel: ???
wenn du selbst kompilierst musst du deine eigene dpl nehmen (vermutl. heist die dann vcl100.dpl), oder lässt den Package-support weg ;)
evtl.wurde die Eigenschaft von Borland umbenannt oder hat andere Parameter...hatte ich schonmal irgendwo, dass eine Eigenschaft einen geänderten Namen hatte...wenn dem so ist, wäre eine lösung hilfreich, die man evtl. per compilerschalter aktivieren könnte

Gruß Frank

[DevilsCamp]

Eben nicht.
Ich kann es ja auch kompilieren. Eigentlich meckert da ja der Compiler schon rum, wenn ich eine Eigenschaft benutze, die nicht vorhanden ist.

Zitat:

Zitat von _frank_

ich hoffe, du hast die vcl30.dpl nur ins Programmverzeichnis kopiert und nicht nochmal separat bei den packages hinzugefügt...

Gruß Frank

Natürlich liegt sie nur im Programmverzeichnis.

[uligerhardt]

Zitat:

Zitat von _frank_

wenn du selbst kompilierst musst du deine eigene dpl nehmen (vermutl. heist die dann vcl100.dpl), oder lässt den Package-support weg ;)

Ich hab Vcl30 durch vcl;rtl ersetzt. Damit hat's funktioniert.

Zitat:

Zitat von _frank_

evtl.wurde die Eigenschaft von Borland umbenannt oder hat andere Parameter...hatte ich schonmal irgendwo, dass eine Eigenschaft einen geänderten Namen hatte...wenn dem so ist, wäre eine lösung hilfreich, die man evtl. per compilerschalter aktivieren könnte

Nicht dass ich wüsste. Sonst hätte es ja bei mir auch nicht funktioniert.

[uligerhardt]

Zitat:

Zitat von _frank_

die man evtl. per compilerschalter aktivieren könnte

A propos Compilerschalter - ich hab Teletubbie-Support ins *.dpr gebaut:

Delphi-Quellcode:

uses
  Forms,
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion >= 15}
  XPMan,
{$IFEND}
{$ENDIF}
  main_u in 'main_u.pas' {Form_DFMMain},

Bei der 15 bin ich mir nicht hundertprozentig sicher. Das könnten geneigte D7(?)-Nutzer ja mal ausprobieren.

[DevilsCamp]

Geht mir das nur so oder haben andere auch das Problem:

Ich habe auf meinem Rechner Delphi7 Pro und Turbo Delphi Explorer für Win32.
Aber auf KEINER Platte habe ich auch nur eine .DPL Datei. Nur .BPL Dateien.



Ausserdem bekomme ich folgende Fehlermeldung, wenn ich versuche das Projekt OHNE Laufzeit-Packages zu kompilieren:

Delphi-Quellcode:

[Pascal Fataler Fehler] dfmedit.dpr(29): F2051 Unit StdCtrls wurde mit einer unterschiedlichen Version von Consts.SErrorSettingCount compiliert

edit:
Diese Meldung kommt sowohl bei Delphi7 als auch bei Turbo Delphi

[uligerhardt]

Zitat:

Zitat von DevilsCamp

Geht mir das nur so oder haben andere auch das Problem:

Ich habe auf meinem Rechner Delphi7 Pro und Turbo Delphi Explorer für Win32.
Aber auf KEINER Platte habe ich auch nur eine .DPL Datei. Nur .BPL Dateien.

Packages haben AFAIK früher dpl geheißen (vermutlich Delphi Package Library). Mittlerweile heißen sie bpl (Borland P..., vermutlich, um die BCB-User nicht zu ärgern. :-)). Das musst du in dem OpenFileDialog auf der Optionform umstellen.

Zitat:

Zitat von DevilsCamp

Ausserdem bekomme ich folgende Fehlermeldung, wenn ich versuche das Projekt OHNE Laufzeit-Packages zu kompilieren:

Delphi-Quellcode:

[Pascal Fataler Fehler] dfmedit.dpr(29): F2051 Unit StdCtrls wurde mit einer unterschiedlichen Version von Consts.SErrorSettingCount compiliert

edit:
Diese Meldung kommt sowohl bei Delphi7 als auch bei Turbo Delphi

Da fällt mir nur ein, dass deine Suchpfade (delphiweit oder projektspezifisch) verbuchselt sein könnten. Aber in beiden IDEs???

[_frank_]

kommentiert die consts.pas aus der dfmedit.dpr aus...sollte eigentlich der compilerschalter deaktivieren ($IFDEF VER*). ist ne englische consts-pas von delphi 3.
//edit
folgendes construkt sollte eigentlich die consts.pas nur bei delphi3-compiler mit einbinden (warum das nicht geht, kann ich leider nicht sagen, evtl sind die versionsabfragen in der DPR nicht gültig):

Delphi-Quellcode:

  {$IFDEF VER100}
  Consts in 'CONSTS.PAS',
  {$ENDIF}

//edit
um den fehler mit den doppelten package-Einträgen zu beheben folgende Zeile in
pref_u.pas Zeile 50 einfügen
Form_DFMOptions.Listbox1.Items.clear;

danach schauen, ob die einträge in der dfmedit.ini auch mehrfach auftauchen (section packages)

Gruß Frank

[_frank_]

ich hab die beiden neuen Funktionen mal in die normale Oberfläche integriert.
weiterhin war ein Fehler in der code-generierung (beim Zusammenfassen gleicher Klassen).
der Bug mit den doppelten Paketen ist natürlich auch gefixt.

evtl. fällt jemand ein guter Name für die Funktionen ein ("Laufzeitcode erstellen" und "unerwünschte Eigenschaften löschen" klingt besch...) ;)

den "Teletubbie-Support" hab ich auch übernommen, wenn das jemand testen möchte (D3 hat kein XPMan)

Sagt bitte bescheid, ob die neuen Funktionen sind wie gewünscht, bzw. was noch verändert werden soll...

weiterhin ist es in dieser Version (0.2.0.4 ) möglich copy/cut/paste auch mit multiselection zu verwenden. evtl. verstecken sich auch hier Fehler (meine tests liefen fehlerfrei).
ich habe außerdem noch eine funktion zur Bestimmung des Index bei Imagelisten hinzugefügt...das activecontrol muss ein Spinedit auf dem Tab_Imagelist sein. wenn man jetzt auf eins der images klickt wird sein index in das spinedit geschrieben...

Zitat:

Zitat von uligerhardt

Hast du schon mal geschaut, was in TGraphic.DefineProperties abgeht?

defineproperties setzt den handler zum schreiben/lesen der dfm, in der entsprechenden Methode wird SaveToStream des jeweiligen Grafiktypes (TBitmap/TIcon/...) aufgerufen. nur ich habe keine ahnung, wie ich dies sinnvoll verwenden kann. da das grundproblem bleibt (zusätzlicher header, teilweise unbekannt).

//edit:
unwanted.obj geändert und angehängt
noch ein bug:
löschen in der Packageliste löscht nicht in ini
Options_u.pas:224:ini.EraseSection('packages');

Gruß Frank

[_frank_]

hab jetzt den OI bei multiselect aktiviert (wenn gleiche typen markiert sind).
Link im ersten posting, vcl30.dpl auf der beta-seite

bei unterschiedlichen typen würde der OI nur noch left/top/height/width/align enthalten. alles andere ist imho zu rechnenintensiv (bei jeder markierungsänderung alle controls durchgehen, deren properties holen und nicht vorhandene aus ursprungsliste löschen)

weiterhin hab ich eine positions-anpassung beim einfügen eingebaut, da es sein kann, dass ein eingefügtes control im neuen parent nicht mehr sichtbar ist (wenn parent kleiner als altes parent)

die bugs
- beim paket-löschen
- fehlendes update im OI wenn Eigenschaft durch dialog geändert wurde
sind behoben und ereignisse werden aus treeview ausgelesen[delphi]

Gruß Frank

[DevilsCamp]

Funktioniert eigentlich inzwischen das einbinden von Turbo-Delphi BPLs?

Bisher war konnte ich die zwar angeben, die Komponenten in dem BPL waren DFMEdit jedoch unbekannt.

[_frank_]

die packages die eingebunden werden sollen müssen mit dem gleichen compiler erstellt worden sein wie die exe. d.h. wenn du packages von turbo-delphi einbinden willst musst du dfmedit auch mit turbo-delphi übersetzen.
Ich kann an der Auf-/Abwärts-Kompatibilität von Packages leider nichts machen. Ist eine funktion, die regeln von Borland unterliegt und nicht meinen ;(

Falls es trotzdem nicht klappt, probiere mal das Testpackage aus der zip-datei zu kompilieren und dein kompilat zu importieren (die test.dpl nicht mit entpacken => d3-binärpackage).

hast du die neuen Funktionen schon probiert?
aso, ein Grid für die Ausrichtung im Preview hat die 0.2.0.5 auch ;)

HTH Frank

[uligerhardt]

Zitat:

Zitat von DevilsCamp

Funktioniert eigentlich inzwischen das einbinden von Turbo-Delphi BPLs?

Bisher war konnte ich die zwar angeben, die Komponenten in dem BPL waren DFMEdit jedoch unbekannt.

Nach meiner Erfahrung musst du explizite RegisterClass-Aufrufe in die Packages einbauen,
damit DFMEdit die enthaltenen Komponenten findet. Delphi kann das irgendwie auch ohne,
vermutlich mit mehr oder weniger gut dokumentierter RTTI.

[_frank_]

Jepp, darauf wollte ich hinaus...das beispiel zeigt, wie ein package aufgebaut sein muss, damit es in dfmedit funktioniert.
nur wenn es mit dem beispiel nicht geht, hat borland etwas geändert...

Gruß Frank

[DevilsCamp]

Ich habe gerade mal die aktuellste Beta mit Turbo Delphi kompiliert.
Ebenso das Testpackage, welches ich dann in der Packageliste in den Optionen stehen sehe.

Doch die Komponente "MyShape", die in diesem Package ist, wird von DFMEdit NICHT zur Auswahl angeboten.

[_frank_]

die Komponentenauswahl enthält nur die sections, die in der components.obj definiert sind...
versuche mal ein TMyShape zu erstellen (im Add-Dialog müsste, nachdem bei Typ TMyShape steht, auch die Hierarchie angezeigt werden...).

zum testen mal eine dfm-definition...

Delphi-Quellcode:

object Form1:TForm1
  BorderStyle = bsSizeable
  Caption = 'Form1'
  Height = 300
  Left = 10
  Top = 10
  Visible = True
  Width = 400
  object MyShape1: TMyShape
    Width = 120
    Visible = True
    Top = 10
    Left = 10
    Height = 21
  end
end

HTH Frank

[DevilsCamp]

Also das funktioniert dann.

Allerdings nicht mit den Komponenten aus dem dclusr-Package. :(

[_frank_]

wie schon gesagt wurde, es muss RegisterClass für jede komponente aufgerufen werden, die verfügbar sein soll. siehe die demo (initialization/finalization)...


HTH Frank