Firemonkey Workarounds

[Harry Stahl]

Zitat von Sir Rufo:

Warum keine Factory?

So muss man sich ja diesen String irgendwie zusammenbasteln. Geht, aber ist auch nicht wirklich schön.

Delphi-Quellcode:

THeaderItemFactory = class
  function Build( const AText : string; AWidth :  Integer ) : THeaderItem;
end;

Der Factory-Instanz gibt man alle relevanten Teile im constructor mit und erzeugt dann die jeweiligen Items.

Der Vorteil bei meiner Lösung liegt m.E. darin, dass ich mit einem Aufruf alles (also z.B. auch Parent, Höhe des THeaders, Ausrichtung, usw) erledigt habe. Das Zusammenbasteln des Strings ist ja nur eine kurze Eingabe der benötigten Werte, sollte eigentlich nicht schwer sein.

Würde aber dennoch gerne verstehen, welche Vorteile Du mit dem Factory-Ansatz siehst. Wird das dann nicht wieder mehr Schreiberei, oder wie ungefähr müsste man sich die Implementation vorstellen?

[Harry Stahl]

Zitat von Union:

Zitat von Harry Stahl:

Hier ist der Eintrag: http://qc.embarcadero.com/wc/qcmain.aspx?d=123746

Also ich kann das nicht reproduzieren.

Sagt interessanterweise auch der Prüfer bei QC. Werde daher Delphi XE5 mal auf einer anderen Entwicklungsmaschine frisch aufsetzen und dann die Form öffnen, danach z.B. TMS installieren, wieder öffnen und so hoffentlich raus finden, ab wann eine Installation von zusätzlichen Dingen einen Effekt hat.

Du vermutest ja die TMS-Komponenten. Aber kann das sein, wenn ich in der Beispielform ja gar keine solchen Komponenten drin habe? Kann das alleinige Vorhanden sein des TMS-Packages auf dem PC so etwas verursachen?

[Union]

Versuch erst mal das Beispiel in einem neuen Verzeichnis zu entpacken und dort zu reproduzieren - so habe ich das ja auch gemacht. Dann kannst Du immer noch ein "frisches" XE5 aufsetzen mit allen Updates und Hotfixes.

[Harry Stahl]

Zitat von Union:

Versuch erst mal das Beispiel in einem neuen Verzeichnis zu entpacken und dort zu reproduzieren

Hatte ich natürlich auch schon in einem separaten Verzeichnis gemacht.

[Sir Rufo]

Zitat von Harry Stahl:

Der Vorteil bei meiner Lösung liegt m.E. darin, dass ich mit einem Aufruf alles (also z.B. auch Parent, Höhe des THeaders, Ausrichtung, usw) erledigt habe. Das Zusammenbasteln des Strings ist ja nur eine kurze Eingabe der benötigten Werte, sollte eigentlich nicht schwer sein.

Würde aber dennoch gerne verstehen, welche Vorteile Du mit dem Factory-Ansatz siehst. Wird das dann nicht wieder mehr Schreiberei, oder wie ungefähr müsste man sich die Implementation vorstellen?

Deine Lösung erscheint aber auch nur auf den ersten Blick vorteilhaft (alles so schön zusammen).

Stell dir einmal dieses Interface vor

Delphi-Quellcode:

IHeaderBuilder = interface
  function AddItem( const ATitle : string ) : IHeaderBuilder; overload;
  function AddItem( const ATitle : string; AWidth : Integer ) : IHeaderBuilder; overload;
  function AddItem( const ATitle : string; AWidth : Integer; AClickHandler : TNotifyEvent ) : IHeaderBuilder; overload;
  // ... kann beliebig fortgesetzt werden
end;

dann kannst du das Erzeugen der Items in eigenen Routinen auslagern, ohne dort wissen zu müssen auf welche konkrete Instanz sich das auswirkt.

Delphi-Quellcode:

procedure TForm1.PrepareCustomersHeader( AHeader : IHeaderBuilder );
begin
  AHeader
    .AddItem( 'Name' )
    .AddItem( 'Phone', 40 )
    .AddItem( 'email', 80, SendMailOnClick );
end;

Und wie wir sehen ist es nicht ersichtlich ob das jetzt für FMX oder VCL sein soll ... eben, das hängt einfach nur von der Implementierung ab. Die kann man jetzt gemütlich für TListView ,TStringGrid oder welche Listenkomponente auch immer implementieren und trotzdem kann der Anwendungs-Code gleich bleiben.

[Harry Stahl]

Ah ja, wirklich interessant!

Allerdings doch deutlich mehr Arbeit, als eben nur mal diesen kleinen WorkAround zu schreiben. Insofern bleibe ich doch erst mal bei meiner Lösung...

[edit: die ich ja jetzt auch nicht mehr brauche, da ich letztlich doch das Problem aufklären konnte und jetzt wieder ganz normal die Komponente verwenden kann, siehe Eintrag #19 unten]

[Harry Stahl]

Zu dem Problem mit der beschädigten FMX-Datei:

Habe XE5 frisch installiert. Danach FMX-TMS-Komponenten, kein Problem, alles geht. Einige Sachen, die ich installiert habe, kann man nur einmal installieren, kann ich also nicht ein zweites Mal in die andere Umgebung installieren. Wie findet man das jetzt nur raus, wo das dran liegen könnte?

[Union]

Du könntest Versuchen, Delphi mit Delphi zu debuggen (Mit Prozess verbinden). Also zuerst den Debuggee starten, im Taskmanager die Prozeß-ID merken und dann Delphi nochmals als Debugger starten (aus der Kommandozeile mit Parameter /np) und mit der BDS.exe mit der zuvor gemerkten ID verbinden. Dann in die erste Instanz wechseln und Fehler verursachen, in die zweite Instanz umschalten und schauen, ob Du was siehst (z.B. BPL-Namen).

Mist, merke gerade das geht mit XE nicht mehr, ausser man startet bei mit /np.

[Harry Stahl]

Und wieder mal ein Mysterium gelöst...

Union, Deine Vermutung, es lag an den TMS-Komponenten, stimmte!!

Allerdings lag es nicht an den TMS-FMX-Komponenten, sondern an den TMS-VCL-Komponenten.

Als ich die defekte FMX speicherte und wieder lud, fiel mir auf, dass plötzlich folgende Einträge in der Form.pas-Datei drin waren:

GDIPCustomItem, GDIPTextItem, GDIPSectionItem,
GDIPImageSectionItem, GDIPHeaderItem;

Die gehören zu den TMS-VCL Komponenten und in der Unit GDIPHeaderItem ist auch eine Klasse "THeaderItem" drin. So kam es zu einem Konflikt. Wie das letztlich möglich sein kann, ist mir zwar ein Rätsel, aber gut.

Nachdem ich also die Packages der TMS-VCL-Komponenten deaktiviert hatte, konnte ich die Datei ganz normal laden.

So, jetzt muss ich das noch EMBA und TMS-Software erzählen... (na toll )

Wie war das eigentlich noch mal: Kann man Delphi nicht so einstellen, dass für bestimmte Projekte nur bestimmte Packages geladen werden? Dann könnte man das Problem vielleicht umgehen?

[Union]

Zitat von Harry Stahl:

Wie war das eigentlich noch mal: Kann man Delphi nicht so einstellen, dass für bestimmte Projekte nur bestimmte Packages geladen werden? Dann könnte man das Problem vielleicht umgehen?

Ja, aber die Packages müssen sich auch daran halten.