FMX: XE7: TDateEdit braucht viel Zeit zur Erzeugung

[Harry Stahl]

Jedes TDateEdit, das auf einer Form liegt, braucht ca. 300 MS (gemessen auf meinem Computer) zur Erzeugung (bei XE6 waren es 0 MS). Hat man einige davon auf der Form, ist das nicht mehr akzeptabel.

Ich habe das mal bei QC gemeldet: http://qc.embarcadero.com/wc/qcmain.aspx?d=127958

Anliegend auch das Demo-Projekt, was das belegt.

Hat Jemand schon mal mit dem Problem zu kämpfen gehabt und kennt einen WorkAround?

Die entsprechende TMS-Kalenderkomponente kann ich leider nicht verwenden, da Sie unter MAC OS X nicht funktioniert.

Edit: OK, hatte vergessen das Projekt neu zu zippen, wo ich meine hilfsunit weglasse. Anliegend nun ohne hilfsunit.

[Alex_ITA01]

Projekt lässt sich nicht compilieren...
Unit "hs_tools_fmx" nicht gefunden

Edit: Habe mal deine persönliche Unit rausgelassen und getestet. Ist bei meinem XE7 auch so :-(
Selbst wenn du im Objektinspektor die 3 Kompos markierst und an eine neue Stelle einfügst (auf der gleichen Form), wirst du arm... Ich habe das mal bis zu 36 Stück probiert. Das ist echt heftig.
Das ist kein "kleiner" Bug!

[FrankJ28]

Hallo,
ist das ein reines FMX-Problem, oder ist auch die VCL davon betroffen?
Danke und ciao
Frank

[Harry Stahl]

Habe es zwar nicht getestet, wird aber wohl kaum der Fall sein, da die FMX-Komponente eine ganz andere als die VCL-Komponente ist.

[Union]

Das ist ja schon logisch, dass es so lahm ist. Schließlich wird ja die gesamte Kalenderkonfiguration beim Erzeugen aus einzelnen Controls zusammengebaut. Dazu gehören auch mehrere Listboxen mit Einträgen für Tage, Monate und Jahre, Label für Wochentage, Kalenderwochen usw. Eine Beschleunigung ließe sich nur erzielen wenn man Teile davon über mehrere Controls sharen würde.

[mkinzler]

Aber das war auch schon bei XE6 so, und hat nicht so lange benötigt. das gleiche Problem scheinen aber auch FastReports auf dem Mac zu haben

https://www.youtube.com/watch?v=EXfwcOG5Rio

[Harry Stahl]

Ja, in XE6 ist die Erzeugung nicht messbar. Problem liegt irgendwo im Bereich des Ladens der Ressource. Bin mal ein wenig mit dem Debugger rein, aber wo es genau liegt, habe ich nicht rausgefunden. So ein einfacher WorkAround scheint nicht möglich zu sein.

Ich hoffe EMBA fixt das schnell.

[Harry Stahl]

Na, bis EMBA fertig ist, mit der Bug-Korrektur, so lange wollte ich nicht warten. Habe daher mir mit einem Frame eine einfache Kalender-"Komponente" selber gebaut.

Die hat die gleichen Eigenschaftswerte (jedenfalls soweit ich diese Komponente benutze), dann kann ich die mit einem Rutsch wieder austauschen, wenn es eine Korrektur von EMBA gibt.

In der Anlage mal 2 Screenshots von der MAC-Version (siehe Anlage). Windows-Version ist nun mit XE7 fertig gestellt und im Vertrieb.

Gerade macht mir richtig Spaß, mit dem Multiview-Designer die Formulare auf MAC-spezifische Anzeige-Bedingungen anzupassen. Das geht wirklich schnell und einfach.

[arnof]

ich denke das ist ein Refresh Problem, das gefühlte 200.000 mal aufgerufen wird:

Auszug aus den nativen D.P.F Komponenten:

Delphi-Quellcode:

7) This is very important to: if you want have very high performance in your project override in all you TForm declrations PaintRects
  Sample:

type
  TFDatePicker = class( TForm )
  private
    { Private declarations }
  protected
    procedure PaintRects( const UpdateRects: array of TRectF ); override; <---- This line a important !
  public
    { Public declarations }
  end;

and in your implementation:

procedure TFDatePicker.PaintRects( const UpdateRects: array of TRectF );
begin
{} <-- This is important you not have any [inherited] keyword here !
end;

hier solltest Du am OnCreate den Refresh irgnorieren und erst am ab dem OnShow zulassen

[Sir Rufo]

@arnof

Diese Methode wird beim Start eines Formulars (ein paar

Delphi-Quellcode:

TDateEdit

auf der Form) genau 2 mal aufgerufen und auch nachdem

Delphi-Quellcode:

DoShow

erfolgte (die Form ist also sichtbar).

Bringt also nichts