Firemonkey Workarounds

[Harry Stahl]

Zitat von greenmile:

Hallo,

da ich während meiner Entwicklung unter Firemonkey über einige Bugs gestolpert bin, die man teilweise recht einfach umgehend kann, möchte ich hier immer mal wieder einige Workarounds reinschreiben. Vielleicht klinkt sich ja der eine oder andere an. Und vielleicht geschieht ja ein Wunder und jemand von Embar liest mit ... Betrifft alles XE2, aktuell Hotfix

...

4- THeader: Werden HeaderItems hinzugefügt, ist die .FMX Datei anschließend defekt
Beim laden der Datei kam es zum Meldung "Ungültige Eigenschaft Headeritem1.Width, außerdem sind plötzlich andere Komponenten auf der Form verschwunden.
Einzig mir bekannter Workaround: THeaderItem dynamisch erzeugen:

...

So, dieser schöne Fehler ist mir nun auch begegnet. Anscheinend hat hier von EMBA leider keiner mitgelesen, denn in XE5 ist das Problem noch (oder wieder) vorhanden. In einem XE3-Projekt nutze ich einen THeader ohne Probleme.

Ein wenig zur Ehrenrettung von EMBA: Im Quality Central gab es aber auch keinen einzigen Eintrag zu diesem Problem.

Das habe ich nun nachgeholt und ein für die Prüfer reproduzierbares Beispiel beigefügt.

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

[Harry Stahl]

Außerdem habe ich nun mal den Workaround-Vorschlag von Greenmile aufgegriffen und eine kleine Prozedur draus gemacht, so dass man mit einem Aufruf den Header, die Höhe des Headers, die Items, die jeweilige Breite der Items, die Captions der HeaderItems, die Ausrichtung des Headers, den Parent und ein ClickEvent übergeben kann.

Sieht dann so aus (die Unit StrUtils und FMX.Header wird benötigt):

Delphi-Quellcode:

Procedure CreateANewHeader (AH: THeader; AHeight: Integer; AClickEvent: TNotifyEvent; AParent: TFMXObject; AL: TAlignLayout; SInfo: String);
var
  DyA: TStringDynArray; s: string; HI: THeaderItem; P: Integer;
begin
  AH := THeader.Create(AParent);
  AH.Parent := Aparent;
  AH.Height := Aheight;
  AH.Align := AL;

  DyA := SplitString (SInfo, ',');

  for s in DyA do begin
    P := Pos ('=', S);

    HI := THeaderItem.Create(AH);
    HI.Parent := AH;
    HI.Text := Copy (S, 1, p-1);
    HI.DragMode := TDragMode.dmManual; // Ohnen diesen Fix geht das ClickEvent nicht :-(
    HI.Width := StrToInt (Copy (S, p+1, Length (s)-P+1));

    if Assigned (AClickEvent) then HI.OnClick := AClickEvent;
  end;
end;

Das könnt Ihr dann so aufrufen (unterstellt, pnSizeBack ist hier z.B. ein TPanel):

var
BillHeader: THeader;

Delphi-Quellcode:

procedure TF_Main.FormCreate(Sender: TObject);
begin
  CreateANewHeader (BillHeader, 21, HeaderItemXClick, pnSizeBack, TAlignLayout.alTop,
   'Re-Datum=89,Re-Nr=64,Anl.=30,Name=176,Summe=100,ZS=24,Zahldatum=83');
  ...
end;

Ein Beispiel für die Event-Prozedur:

Delphi-Quellcode:

procedure TF_Main.HeaderItemXClick(Sender: TObject);
begin
  ShowMessage ('Clicked: ' + THeaderItem(sender).Text);
end;

[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.

[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?

[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]

Zitat von Harry Stahl:

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

Also ich kann das nicht reproduzieren. Wenn ich in pnSizeback in Form48 einen THeader und darin dann HeaderItems hinzufüge, sind die nach dem Speichern, Schließen und wieder Laden wieder da. Auch Dein angehängtes Form49, das den Fehler bereits enthalten soll kann ich problemlos laden (s. Anhang). Evtl. hast Du eine bpl geladen, die ein solches Fehlverhalten bei Dir auslöst. Höchstwahrscheinlich die TMS-Komponenten.

[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.