FireMonkey Sammelthread

[stahli]

Ich will man temporär eine Statusbar einblenden (nicht meckern, es ist eine Spielerei) und ein Label für einen Zähler nutzen.
Die Aktualisierung des Formulars erfolgt erst nach der Prozedur.

Wie kann man zwisdchendurch refreshen? Ich dachte, FM wäre da direkter als die VCL...

Delphi-Quellcode:

procedure TFormPersonsGrid.Insert10000;
var
  I: Integer;
  DS: TSQLDataSet;
  Id: Integer;
  FieldName: string;
begin
  beep;
  StatusBar.Visible := True;
  StatusBar.Repaint;
//  Self.Update; ???
  for I := 0 to 1000 - 1 do
  begin
    LabelStatus.Text := Format('%d', [I]);
    BlaBlaBla;
  end;
//  StatusBar.Visible := False;
  beep;
  FillGridData;
end;

[stahli]

Ich spiele gerade mal an einem kleinen DataBinding-Framework herum.
Ich kann u.a. schon mit einer Checkbox Edit1.Enabled umschalten.
Das funktioniert "funktional" auch wie erwartet, aber die Controls werden nicht neu gezeichnet bzw. erst wenn ich das Formular minimiere und wieder herstelle.

Ein ausdrückliches Repaint hilft auch nicht weiter.

Delphi-Quellcode:

procedure TssfCtrl.set_PropText(const Value: string);
begin
  if Assigned(BindObject) then
  begin
    SetPropValue(BindObject, PropName, Value);
//    if (BindObject is TControl) then
//      (BindObject as TControl).Repaint; // hilft nicht
  end;
end;

Weiß jemand auf Anhieb, wo es mangelt? Vermutlich muss noch das Formular den Auftrag erhalten, sich neu zu zeichnen.
Invalidate - wie in der VCL - gibt es ja nicht.

[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

[bytecook]

Zitat von 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) ?

Screenshots muss ich erst machen, anbei aber der Link zu den Anleitungen
In der Anleitung sind einige Screenshots drinnen...

Screenshots meiner bereits fertigen FM2 Programme in den Manuals

SG6 Manual 'Draft'
SCD Usermanual

Zu den Daten: Habe meine eigene Stream Datenversorgung, Properties werden direkt beschickt
und kommen ohnen Bindings aus.
(Viele Komponenten werden erst zur Laufzeit bei Bedarf erzeugt)

FindStyleResources ist innerhalb meiner Komponenten gekapselt und wird nur zum
Subcomponent-Fetchen verwendet

Delphi-Quellcode:

(******************************************************************************)
function TSTBFMXBasePanel.GetRadioButton (Value : String) : TSTBFMXRadioButton;

  var fmxobj : TFMXObject;

  begin
    fmxobj := FindStyleResource(Value);
    if assigned(fmxobj) then
      if fmxobj is TSTBFMXRadioButton then Result := fmxobj as TSTBFMXRadioButton
                                      else Result := nil;
  end;
(******************************************************************************)

Ja, SI und CI sind schon erklärt


Grüße,

Peter

[bytecook]

Zitat von stahli:

Ich spiele gerade mal an einem kleinen DataBinding-Framework herum.
Ich kann u.a. schon mit einer Checkbox Edit1.Enabled umschalten.
Das funktioniert "funktional" auch wie erwartet, aber die Controls werden nicht neu gezeichnet bzw. erst wenn ich das Formular minimiere und wieder herstelle.

Ein ausdrückliches Repaint hilft auch nicht weiter.

Delphi-Quellcode:

procedure TssfCtrl.set_PropText(const Value: string);
begin
  if Assigned(BindObject) then
  begin
    SetPropValue(BindObject, PropName, Value);
//    if (BindObject is TControl) then
//      (BindObject as TControl).Repaint; // hilft nicht
  end;
end;

Weiß jemand auf Anhieb, wo es mangelt? Vermutlich muss noch das Formular den Auftrag erhalten, sich neu zu zeichnen.
Invalidate - wie in der VCL - gibt es ja nicht.

Wie siehts mit einem .Realign Aufruf der Komponente aus?
Oder verwende mal BeginUpdate/Dein Code/EndUpdate ...

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