FireMonkey Sammelthread

[Union]

Zitat von greenmile:

Bräuchte ich Firemonkey für Multiplattform (Mac, Android und co) nicht, könnte ich getrost drauf verzichten

Zeig mir mal 'ne Demo von so einer Crossplatform-Anwendung.

[greenmile]

Du hast PM

[stahli]

Wie war das? Eine Ableitung erbt alle Eigenschaften seines jeweiligen Vorgängers???

Mein Projekt hat mich zur Verzweiflung gebracht. Die zweite spezialisierte Ableitung eines Edits (die erste implementiert ein Databinding und die zweite soll in ein Gitter eingepasst werden) wurde einfach nicht angezeigt. !!!???
Zwar wurden Eingaben in die Datenschicht geschickt aber auf dem Bildschirm nichts angezeigt.

Dann habe ich das Problem immer weiter vereinfacht und festgestellt, dass der zweiten Ableitung keine StyleRessource mehr zugewiesen ist.

Delphi-Quellcode:

procedure TCustomEdit.ApplyStyle;
var
  T: TFmxObject;
begin
  inherited ApplyStyle;
  if FInputSupport then
    Cursor := crIBeam
  else
    Cursor := crDefault;
  T := FindStyleResource('content'); // <--- StyleRessource verwenden
  if Assigned(T) and (T is TControl) then
  begin
    FContent := TControl(T);
    FContent.OnPaint := DoContentPaint;
  end;
  T := FindStyleResource('selection');
  if Assigned(T) and (T is TBrushObject) then
  begin
    FSelectionFill.Assign(TBrushObject(T).Brush);
  end;
  { from style }
  T := FindStyleResource('foreground');
  // apply the font fill style only if the user hasn't changed the font fill anteriorly
  if (not FFontColorBeforeStyle) and Assigned(T) and (T is TBrushObject) then
    FFontColor := TBrushObject(T).Brush.Color;
  T := FindStyleResource('font');
  if (not FFontBeforeStyle) and Assigned(T) and Supports(T, IFontObject) and not Font.IsSizeStored then
    FFont.Assign((T as IFontObject).Font);
  { Container for store buttons}
  T := FindStyleResource('buttons');
  if Assigned(T) and (T is TControl) then
  begin
    FButtonsLayout := T as TControl;
    RealignButtonsContainer;
  end;

  // now we are sure that if the user changed the font fill before style application,
  // the correct information will be reflected; change the switches so that from now on
  // we have the normal flow of style application
  FStyleApplied := True;
  FFontBeforeStyle := False;
  FFontColorBeforeStyle := False;
end;

function TStyledControl.FindStyleResource(const AStyleLookup: string): TFmxObject;
begin
  Result := nil;
  if Assigned(FResourceLink) then // <-- ist bei TEdit und TEditA zugewiesen aber bei TEditB=NIL !!!???
    Result := FResourceLink.FindStyleResource(AStyleLookup);
  if Not Assigned(Result) then
    Result := inherited FindStyleResource(AStyleLookup);
end;

Anbei ein kleines Demoprojekt für XE3 und hier mal der Quelltext:

Delphi-Quellcode:

unit fRessourceTest;

interface

uses
  System.SysUtils, System.Types, System.Rtti, System.Classes,
  System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, FMX.Edit;

type
  TForm1 = class(TForm)
    Panel1: TPanel;
    Button1: TButton;
    Button2: TButton;
    Panel2: TPanel;
    Button3: TButton;
    Panel3: TPanel;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

uses
  System.UITypes;

type

  TEditA = class(TEdit)
  end;

  TEditB = class(TEditA)
  end;

{$R *.fmx}

procedure TForm1.Button1Click(Sender: TObject);
begin
  TEdit.Create(Self).Parent := Panel1;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  TEditA.Create(Self).Parent := Panel2;
end;

procedure TForm1.Button3Click(Sender: TObject);
begin
  TEditB.Create(Self).Parent := Panel3;
end;

end.

Hat jemand eine Erklärung?
Kann jemand helfen?
Wie kann ich die "originale" Style-Ressource zuordnen?

So langsam wird mir FMX wirklich suspekt, wobei ich zwischendurch auch schon ein paar nette Dinge realisieren konnte (und auf dem Weg weiter voran kommen wollte).

Zwischenfazit:
- LiveBindings sind Schrott
- Styles sind für den Komponentenbau unzweckmäßig (für Füllmuster u.ä. ok aber nicht für funktionelle Bestandteile)
- sonst ist das Konzept (Win-Unabhängigkeit und freie Scalierbarkeit) aber schon vielversprechend

[stahli]

Das Verhalten der Scrollbar ist ungünstig:
Wenn man in den Scrollbereich klickt wird der Positionszeiger beim MouseUp an die Klickposition gesetzt.

Besser wäre wenn die Scrollbar beim MouseDown "seitenweise" in Richtung und bis zur Klickposition springen würde (bzw. bis man loslässt).
So ist das ja auch in der VCL.

Alternativ sollte die Scrollbar wenigstens schon beim MouseDown zur Klickposition springen.


Die böse Stelle habe ich gefunden, aber nachträgliche Korrekturen sind vermutlich aufwändig (zumal die Funktionalität in ein Subcontrol verlagert ist), weshalb ich das erst mal aufschiebe.
(Mit einem schnellen Update ist wohl nicht zu rechnen ;-( )

Delphi-Quellcode:

procedure TCustomTrack.MouseUp(Button: TMouseButton; Shift: TShiftState; X, Y: Single);
var
  LValue: single;
begin
  LValue := Value;
  inherited MouseUp(Button, Shift, X, Y);
  DoMouseUp(Button, Shift, X, Y, LValue); // <---
end;

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

[Mavarik]

Hallo Zusammen!

Wie kann ich verhindern, dass die "interne" Tastatur (iPhone/iPad) beim Focus auf eine TEdit eingeblendet wird?

Grüsse Mavarik

[Sir Rufo]

Zitat von stahli:

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

Das Formular muss keineswegs synchronisiert werden. Allerdings scheint es so, dass zum Zeitpunkt der Events noch nicht alles fertig berechnet ist oder Events verschluckt werden (warum auch immer, ist halt komisch).

Das das mit dem Thread funktioniert hat eine andere Ursache

TThread.Synchronize wartet bis der MainThread im Idle Zustand ist. In den Idle Zustand geht der MainThread dann, wenn es für den nichts mehr zu tun gibt ... ausser auf Events/Messages zu warten. Erreichen kann man das auch mit einem Timer (der Thread ist da schon besser, aber mir geht es darum zu zeigen, dass es nichts mit Synchronisieren zu schaffen hat).

Hier mal eine ganz billige Demo mit einem TStringGrid (Align:=alClient ) und im OnResize Event lassen wir uns die ClientWidth ausgeben. (Das Panel ist nur als Container für die beiden Labels gedacht).

Dabei sieht man, dass der Wert beim EventAufruf dem endgültigen Wert (TimerEvent) hinterher hinkt.

Delphi-Quellcode:

unit Main_ViewU;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Rtti, System.Classes,
  System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, FMX.Grid,
  FMX.Layouts, FMX.ListBox;

type
  TForm1 = class( TForm )
    StringGrid1 : TStringGrid;
    Panel1 : TPanel;
    Label1 : TLabel;
    Label2 : TLabel;
    Timer1 : TTimer;
    procedure StringGrid1Resize( Sender : TObject );
    procedure Timer1Timer( Sender : TObject );
  private
  public
  end;

var
  Form1 : TForm1;

implementation

{$R *.fmx}

procedure TForm1.StringGrid1Resize( Sender : TObject );
begin
  Timer1.Enabled := False;
  Label1.Data    := StringGrid1.ClientWidth;
  Timer1.Enabled := True;
end;

procedure TForm1.Timer1Timer( Sender : TObject );
begin
  Timer1.Enabled := False;
  Label2.Data    := StringGrid1.ClientWidth;
end;

end.

Trotz dieser Erkenntnis ist dieses Verhalten in meinen Augen fehlerhaft ... evtl. sollte ich mal einen QC Eintrag verfassen (oder vorher danach suchen )

[stahli]

Ja stimmt, ich meinte auch zeitlich mit dem MainThread syncronisieren (nicht kritische Zugriffe)...
Mit dem Thread ist das schon etwas günstiger als mit dem Timer.

Wenn Du das in der QC vernünftig beschrieben kriegst, dann gebe ich Dir eine Milch mit Honig aus...

[stahli]

Gibt es eine Möglichkeit, den Fortschritt einer Progressbar ohne Application.ProcessMessages darzustellen???

[Union]

Wenn es nicht um FM ginge...