FireMonkey Sammelthread

[stahli]

Ich habe noch ein wenig probiert und noch ein paar Punkte herausbekommen - aber keine Lösung gefunden.

Wenn ich aus meinem Framework heraus ein Control neu zeichnen lasse wird bis zum Formular hoch das entsprechende Rect als ungültig deklariert.
Allerdings erreiche ich eine wirkliche Neuzeichnung des Formulars erst durch eine Größenänderung des Formulars.

Im Formular reicht ein Timer, der ein Invalidate ausführt.

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Invalidate;
end;

In meinem Framework ermittle ich das korrekte Form, kann aber kein Neuzeichnen veranlassen.
Mit EndUpdate und ReCreate klappt das aber das Formular wird kurz ausgeblendet und neu gezeichnet.

Delphi-Quellcode:

procedure TssfCtrl.RefreshControl(Control: TControl);
var
  P: TFmxObject;
begin
  if not Assigned(Control) then
    Exit;
  // Control.BeginUpdate;
  // Control.Repaint;
  // Control.EndUpdate;
  // Exit;
  P := Control.Parent;
  while Assigned(P.Parent) do
    P := P.Parent;
  if (P is TForm) then
  begin
    // public Methoden:
    // (P as TForm).Invalidate;  // nix
    //
    // (P as TForm).BeginUpdate;
    // (P as TForm).EndUpdate;   // flackert
    //
    // protected Methoden:
    // TCrackForm(P).Realign;      // nix
    // TCrackForm(P).Resize;       // nix
    // TCrackForm(P).Recreate;     // flackert
    // TCrackForm(P).Updating;     // nix
    // TCrackForm(P).Updated;      // nix
    // TCrackForm(P).UpdateStyle;  // nix
    // TCrackForm(P).ResizeHandle; // nix
  end;
end;

Das Zeichnen meines eigentlichen Controls kann ich an der Stelle sogar weg lassen (wird schon durch die Eigenschaftsänderung veranlasst).

Offenbar kriegt der Mainthread wohl irgendwie von der Änderung nichts mit (obwohl ich gar nicht wirklich sagen kann in welchem Prozess die Änderung gezeichnet wird).
In dem Zusammenhang stellt sich natürlich auch noch die Frage, wie das mit dem Repaint dann unter Mac bzw. auf den mobilen Plattformen laufen würde.

Falls jemand mit meinem Baustellenprojekt (XE3) mal herumspielen will könnte ich das mal per Mail schicken.

[stahli]

Hmm, ich komme an der Stelle nicht wirklich weiter. Sehr rätselhaft...

Also ich bastle ein Databinding-Framework (mal sehen, was draus wird, erst mal ist es auf jeden Fall interessant).
Wenn ich aus einem Edit eine Änderung an die Datenschicht schicke wird die GUI danach über die Änderung informiert und die GUI-Controls werden veranlasst, sich mit den neuen Daten zu zeichnen.

Das funktioniert auch - nur wird die Änderung nicht sichtbar bis ich die Formulargrößere ändere oder z.B. in einem Timer Invalidate für das Formular ausführe.
Der richtige Wert liegt aber dann "nachweislich" ja in den Controls schon vor.

Das komische: Wenn ich aus einem Timer heraus z.B. TimeToStr(Now) in die Datenschicht schicke (anstatt bei einer Texteingabe im Edit) werden die an das Feld gebundenen Controls immer korrekt gezeichnet (bzw. der entsprechende Bereich auf dem Formular). Die anderen Controls aber wiederum nicht.

Wenn bei überschneidenen Controls das andere Control neu gezeichnet wird (z.B. wenn ein Edit focusiert wird), sieht man von dem nicht aktualisierten Control einige Pixel, die jetzt aktualisiert wurden.
Also wurde die Änderung auf dem Screen noch nicht aktualisiert, im Puffer sind die aber schon vorhanden.

Wenn jemand sich in dem Bereich mal beschäftigt, dann wäre ich für einen Tipp dankbar.
(Kann auch gern den aktuellen Stand schicken.)

[Sir Rufo]

Ich habe zwar nicht dieses aber ein Verhalten beobachtet, was wohl die gleiche Ursache hat.

Beim TGrid wollte ich eine Spalte immer so breit machen, dass die gesamte Gridbreite ausgefüllt ist.
Eigentlich ganz einfach: Kleine procedure und im Resize Event des TGrid diese aufrufen.

Aber denkste, das funktioniert nicht immer (eher öfter nicht), allerdings wird das Ereignis zuverlässig aufgerufen jedoch teilweise bevor die Änderungen wirklich stattgefunden haben.

Seltsam, ist aber so ...

Meine Lösung dafür heisst nun, dass ich im Resize Event einen IdleEvent auslöse und der wird erst dann ausgeführt, wenn die Anwendung in den Idle Zustand geht - analog zum TApplicationEvent.OnIdle, nur wird mein Event nur einmal ausgelöst.
Und schon funktioniert es zuverlässig.
(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht )

[stahli]

Zitat von stahli:

Hmm, ich komme an der Stelle nicht wirklich weiter. Sehr rätselhaft...

Also ich bastle ein Databinding-Framework (mal sehen, was draus wird, erst mal ist es auf jeden Fall interessant).
Wenn ich aus einem Edit eine Änderung an die Datenschicht schicke wird die GUI danach über die Änderung informiert und die GUI-Controls werden veranlasst, sich mit den neuen Daten zu zeichnen.

Das funktioniert auch - nur wird die Änderung nicht sichtbar bis ich die Formulargrößere ändere oder z.B. in einem Timer Invalidate für das Formular ausführe.
Der richtige Wert liegt aber dann "nachweislich" ja in den Controls schon vor.

Das komische: Wenn ich aus einem Timer heraus z.B. TimeToStr(Now) in die Datenschicht schicke (anstatt bei einer Texteingabe im Edit) werden die an das Feld gebundenen Controls immer korrekt gezeichnet (bzw. der entsprechende Bereich auf dem Formular). Die anderen Controls aber wiederum nicht.

Wenn bei überschneidenen Controls das andere Control neu gezeichnet wird (z.B. wenn ein Edit focusiert wird), sieht man von dem nicht aktualisierten Control einige Pixel, die jetzt aktualisiert wurden.
Also wurde die Änderung auf dem Screen noch nicht aktualisiert, im Puffer sind die aber schon vorhanden.

Wenn jemand sich in dem Bereich mal beschäftigt, dann wäre ich für einen Tipp dankbar.
(Kann auch gern den aktuellen Stand schicken.)

Das Zeichnen des Formulars muss syncronisiert werden.
Ich nutze dazu in meinem Framework jetzt einen Thread. Das funktioniert in den ersten Tests perfekt.

Delphi-Quellcode:

  TInvalidateThread = class(TThread)
  private
    fForm: TForm;
    procedure DoInvalidate;
  protected
    procedure Execute; override;
  public
    constructor Create(aForm: TForm);
  end;

...

{ TInvalidateThread }

constructor TInvalidateThread.Create(aForm: TForm);
begin
  fForm := aForm;
  FreeOnTerminate := True;
  inherited Create(False);
end;

procedure TInvalidateThread.DoInvalidate;
begin
  if Assigned(fForm) then
    fForm.Invalidate;
end;

procedure TInvalidateThread.Execute;
begin
  inherited;
  Synchronize(DoInvalidate);
end;

[Darlo]

Zitat von stahli:

Im Formular reicht ein Timer, der ein Invalidate ausführt.

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Invalidate;
end;

Danke, das hat mir geholfen Memos und Stringgrids die zur Laufzeit nicht angezeigt wurden (ein Klick auf die Position hat die Komponente dann angezeigt) zu lösen!

[stahli]

@Darlo

Ok, das ist schon mal eine hilfreiche Info.

Kannst Du das Problem reproduzierbar und in verständlichem Englisch in der QC beschreiben?
(Für mich ist das schwierig, weil ich mich mit dem Englisch schwer tue und an einem komplexen Framework arbeite, so dass das Problem nicht problemlos reproduzierbar wäre.)

(roter Kasten hatte Urlaub)

[stahli]

Ein etwas älteres aber interessantes Beispiel für eine GUI unter FMX: http://www.youtube.com/watch?v=AmkEO8QBsBU

Attraktiv ist das schon und man sollte FMX nicht zu früh verteufeln...

[bytecook]

Haben unsere erste Software unter FM2 fertig, diese läuft ganz nett. Habe als "Styles - Lernvorlage" die FM TMS Komponenten genommen,
(Unter KSDEV/FM hab ich Styles von Hause aus vermieden) dann größtenteils unsere eigenen Komponenten mit dementsprechender Komplexität
(Dynamische Subkomponenten, etc) entwickelt.

Die Software läuft unter Windows 7 /8, wir verwenden seit 2007 Touchsysteme im industriellen Umfeld. Die Styles waren anfangs etwas tricky,
neue zu erstellen ist mittlerweile sehr simpel.(Nehme dazu Notepad)

Halte aber fest:

Unsere XE3 Frontend Anwendungen laufen zur Zeit ausschließlich unter Windows 7/8, wechseln keine Styles.

Auch nicht zu vergessen:

Wer keine Styles mag, und schon Komponenten unter VCL entwickelt hat, der kann nach wie in der VCl Brushes/Farben, etc publishen, auch wenn
das manchmal ein Stilbruch sein mag. Besser aber, als immer wieder die Ereignis-OnPaint Methoden für jedes Teil umschreiben zu müssen.

Wenn man aber ein gewisses Maß an SI (CI für SW) erreichen will, dann ist es immer nett, Styles zu verwenden. Ich halte jedoch bei
manchen Komponenten nicht dogmatisch an den Styles fest ...

[stahli]

Kann man mal was sehen (Screenshots/ Demovideo o.ä.)?
Wie bringst Du Daten in die GUI?
Bindung über FindStyleRessource (oder wie das hieß)?

Für was steht: SI (CI für SW) ?

[Sir Rufo]

CI = Corporate Identity
SI = Software Identity