FireMonkey Sammelthread

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

[Unx]

Zitat:

Zitat von Sir Rufo (Beitrag 1198843)

(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht ;))

Für mich hört sich das eher an..... was zu verwenden was man nicht verwenden sollte!

[stahli]

Ich arbeite an einigen FMX-Controls bzw. versuche das.

Irgendwie finde ich die FMX-Controls im Allgemeinen unnötig kompliziert aufgebaut.
Z.B. werden ín einem Header die Items in der Childrenliste gespeichert und dann anhand der Classe herausgesucht.
Das Hinzufügen von Einträgen funktioniert zwar, aber die Breite passt nicht immer und wird erst bei einer Größenänderung des Parent aktualisiert.
Dass AddObject neue Einträge vor dem automatischen ersten Eintrag "addiert" werden ist nicht dokumentiert.
Realign ist nicht öffentlich.

Von der oder anderer Sorte gibt es an allen Ecken Probleme bzw. (für mich) Unklarheiten.
Ohne jetzt Details ausdiskutieren zu wollen hätte ich mir das ganze Framework irgendwie übersichtlicher und klarer strukturiert erhofft.

Seht Ihr das auch so (insb. beim Arbeiten an eigenen Controls)?

[greenmile]

Willkommen im Club :)

[Darlo]

Zitat:

Zitat von stahli (Beitrag 1198434)

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!

[Sir Rufo]

Zitat:

Zitat von Unx (Beitrag 1198844)

Zitat:

Zitat von Sir Rufo (Beitrag 1198843)

(Eigentlich ist das schon fast Holzhammer, aber wer hilft hat erst mal recht ;))

Für mich hört sich das eher an..... was zu verwenden was man nicht verwenden sollte!

Hast ja recht, FireMonkey ist noch Beta und sollte daher in Produktivlösungen nicht verwendet werden ... manchmal kann man aber nicht anders und dann muss man die Bugs eben irgendwie wegbügeln ;)

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

[Union]

Zitat:

Zitat von stahli (Beitrag 1200250)

Ok, das ist schon mal eine hilfreiche Info.

Hattest Du nicht mal gesagt, EMB würde eine "echte" FMX Anwendung zur Verfügung stellen? Was ist damit? Hast Du Feedback?

[stahli]

Das war mein Wunsch, ein reales und nutzbares Beispiel mit den LiveBindings zu sehen: http://www.delphipraxis.net/171665-e...moprojekt.html
David I hatte eine entsprechende Demo versprochen, reagiert aber nicht mehr auf Nachfragen.

Inzwischen ist mir das egal, da ich an einem eigenen Framework (als Alternative zu den LiveBindings) arbeite. Die Ansätze finde ich vielversprechend.
Hier habe ich das mal angesprochen: http://www.delphipraxis.net/172249-d...ml#post1196272
U.a. baue ich gerade an einem eigenen Grid (abgeleitet von einem Panel, also wirklich ein eigenes), das sich dann an diverse Datenmengen binden lassen soll (Listen und DataSets). Gleiches für eine ListBox.

FM2 finde ich nicht schlecht, wenngleich noch nicht ganz ausgereift und an einigen Stellen nicht ganz nachvollziehbar und zu umständlich.
Die Style-Funktionalität finde ich nur bedingt sinnvoll um eigene Controls zu bauen. Ich finde es meist sinnvoller, eigene Controls klassisch aufzubauen da man so besser in´s Detail gehen kann.

[greenmile]

Ich denke man kann es auf den Punkt bringen: Bräuchte ich Firemonkey für Multiplattform (Mac, Android und co) nicht, könnte ich getrost drauf verzichten und es keine Sekunde meines Lebens vermissen. An anderer Stelle habe ich mich auch schon ordentlich zu den Styles geäußert: Wer sich so einen Blödsinn hat einfallen lassen ... Versuch doch mal, einen Style zu wechseln, wenn Du schon eigene Änderungen drin vorgenommen hast. Und zack ... is' alles weg.

[Union]

Zitat:

Zitat von greenmile (Beitrag 1200262)

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??? :wall::wall::wall:

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:

Zitat von stahli (Beitrag 1198839)

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:

Zitat von stahli (Beitrag 1201926)

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

Delphi-Quellcode:

TStringGrid

(

Delphi-Quellcode:

Align:=alClient

) und im

Delphi-Quellcode:

OnResize

Event lassen wir uns die

Delphi-Quellcode:

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

[Thom]

Zitat:

Zitat von stahli (Beitrag 1195518)

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

Hallo Stahli,

auch wenn es etwas spät kommt - hier die Lösung:

Delphi-Quellcode:

 PaintRects([RectF(100,100,200,200)]);
  //...

Die Methode PaintRects des Formulars ist für das (sofortige) Neuzeichnen zuständig. Konstruktionen mit einem Timer oder Threads sind damit überflüssig.

[stahli]

Danke, aber die Methode ist protected.
In Beitrag #119 habe ich mal andere geschützte Methoden versucht, ohne Erfolg.
Hier müsste man jetzt die Formularbereiche ermitteln.

(Ich denke auch, dass FMX die Methode selbst aufruft, will mich aber jetzt nicht nochmal durch das ganze System hangeln.)

Nutzt Du die Methode selbst? Dann gib mal bitte ein Beispiel.

[Thom]

Stimmt - in den Quelltexten sie ist protected. Geht aber trotzdem ohne Probleme: Irgendwie scheinen die gelieferten DCU's nicht mit den Quelltexten übereinzustimmen. Das ist mir schon an vielen Stellen aufgefallen, weil der Compiler Konstanten nicht finden konnte, obwohl sie in den Quellen von Firemonkey enthalten sind. Sollte es bei Dir trotzdem nicht funktionieren, nutze einfach einen Class-Helper.

Die Methode habe ich herausgefunden, nachdem ich den Ablauf der Formularaktualisierung debuggt hatte. Die Methode Repaint bewirkt ja leider nicht wie in der VCL ein Invalidate+Update sondern nur das Invalidate. Insofern ist das eine völlig falsche und irreführende Benennung in Firemonkey.

Ja, ich benutze die Methode selbst. Beim Betätigen eines Buttons wird die Kamera in einem Viewort3D bewegt. Das Bild wird normalerweise erst aktualisiert, nachdem die linke Maustaste losgelassen wurde. Das geht natürlich gar nicht und deshalb hatte ich mich auf die Suche nach einer Lösung begeben. Der Aufruf von PaintRects funktioniert sehr zuverlässig und verzögerungsfrei, da keinerlei Nachrichten geschickt werden und das Repaint unmittelbar ausgeführt wird.

Delphi-Quellcode:

  [...]  
  PaintRects([Viewport3D1.ClipRect]);
  [...]

Das Verfahren funktioniert deshalb sogar in einer For-To-Schleife ohne Application.ProcessMessages oder ähnlichen Dingen.

Insofern hast Du vollkommen Recht: Firemonkey ist viel direkter als die VCL. Die Entwickler müßten es nur mal hinbekommen, die Methoden ordentlich zu benennen und nicht alles in protected oder private-Abschnitten zu verstecken.

[stahli]

Du hast Recht. Hoffen wir mal drauf, dass Emba da noch nachbessert.

Ich merke mir PaintRects mal vor (allerdings müsste man ja sicher auch noch bei Verschachtelungen das Rect des Controls auf dem Formular ermitteln (da meine Controls nicht zwingend direkt im Formular liegen)).
Vielleicht gibt es ja doch mal noch ein Update, so dass man sich das sparen kann.
Bis dahin bleibe ich wohl erst mal (der Einfachheit halber) beim Invalidate.

[Thom]

Ich glaube, da brauchst Du gar nicht so viel zu berechnen:

Delphi-Quellcode:

TControl.UpdateRect

sollte schon den notwendigen Bereich liefern.

[stahli]

FMX hat noch Licht und Schatten, der beigefügte Schatten fällt aber unter Licht! :stupid: (Ja, ja, es ist spät. ;-))

Mit dem Hinzufügen eines einzigen Effektes kann man die GUI optisch ganz schön aufpeppen, was m.E. die Übersichtlichkeit extrem verbessert.
Die Umsetzung in den Bildern ergab sich eher zufällig, ich finde das aber richtig genial so.

Natürlich darf man die Effekte nicht übertreiben aber sie können ein sehr nützliches Mittel sein.

Gefällt Euch das auch?

[Harry Stahl]

Also mir gefällt es auch.

Man wird für die Komponenten selber zwar nur wenige der Effekte verwenden können, ich denke die meisten der Effekte sind eher für Bildbearbeitung gedacht.

Aber die Effekte, die man für Komponenten nutzen kann, wie etwa der TShadoweffekt, sind nützlich. Was z.B. auch geht, ist der TGlowEffekt, mit Trigger MouseOver, dann kann man z.B. hier in bestimmten Situationen den Fokus der Eingabeelemente (z.B. TEdit) noch stärker betonen.

Die ganzen Effekte kann man sich in dem mitgelieferten FireMonkey-Demo "ShaderFilters" einmal ansehen, ziemlich beeindruckend finde ich.

[stahli]

Ja, leider ist die genannte Demo eher auf Grafiken bezogen.
Ich finde interessanter, eine GUI mit sinnvollen Effekten zu optimieren.
Wer Beispiele hat, immer her damit :-)

[Merkur]

Hallo,

ich habe mir im Dezember noch XE3 Prof. zum Aktionspreis zugelegt. Hintergrund u.A.: ich muss ein Programm auf einem Windows Tablet laufen lassen. Mit Umstieg auf Windows 8 (Windows 7 ist meiner Meinung nach nicht wirklich auf Tablets nutzbar) muss ich eben diese App bzw. die Oberfläche für das Tablet portieren.
Das wollte ich zum Anlass nehmen, Delphi XE3 mit Firemonkey und Metro UI erstmalig zu nutzen.

Was mir zunächst aufgefallen ist: Man muss sich wohl mit Styles beschäftigen, die irgendwie nicht intuitiv zu erfassen sind.
Aber mit Padding kommt man schon ziemlich weit...

Allerdings stehe ich nun vor einem Problem, für das ich dringend Hilfe benötige:
Ich muss Daten in ein TEdit eingeben und habe keine Tastatur auf dem Tablet zur Verfügung. Delphi 2010 hatte ja noch ein Touch-Keyboard das funktionierte. Firemonkey wohl nicht.
Demos habe ich bislang keine gefunden, aber es sollte doch wohl eine Lösung geben. Ich bin sicher nicht der Erste mit der Abforderung etwas in ein TEdit einzugeben.

Danke schon einmal im Voraus.

[mjustin]

Zitat:

Zitat von Merkur (Beitrag 1207879)

Das wollte ich zum Anlass nehmen, Delphi XE3 mit Firemonkey und Metro UI erstmalig zu nutzen.

Vielleicht habe ich da etwas verpasst - aber Metro UI (mittlerweile heisst es "Modern UI") wird von Delphi nicht unterstützt.

[Merkur]

In XE3 gibt es zumindest den Punkt:

Datei/Neu/FireMonkey-Anwendung für Metropolis-UI - Delphi

Da kommt dann eine lauffähige Demo-App mit einer Horizontalen-Scroll-Box mit Kacheln etc. bei heraus.

[mkinzler]

Es handelt sich hier aber nur um einen Skin. Es ist keine WindowsRT, sondern eine "normale" Windows-Applikation

[Merkur]

Sorry, das Tablet hat Windows 8 Prof. nicht Windows RT.
Eigendlich ist mir egal, ob das Programm als App oder "normale" Anwendung wie der z.B. der Explorer läuft.
Allerdings sollte man wenigstens ein Password und ein paar wenige Zeilen Text ohne Hardware-Tastatur eingeben können. Wichtig insb. weil das Programm als Vollbild ohne Rahmen läuft.

[stahli]

Laut Wiki soll FM2 ja eine virtuelle Tastatur unterstützen.
http://docwiki.embarcadero.com/RADSt...%2BBuilder_XE3

Ich meine irgendwo in einem Emba-Video gesehen zu haben, dass man die aber explizit ermitteln/aktivieren muss (je nach System für Windows oder OS X).
Vielleicht steht im Wiki ja noch genaueres dazu.

[Merkur]

Der Tip mit dem Video war super! So erscheint die Tastatur:

Delphi-Quellcode:

procedure TLoginViewForm.edPasswordEnter(Sender: TObject);
var
  KBDService : IFMXVirtualKeyboardService;

begin
  if TPlatformServices.Current.SupportsPlatformService(
     IFMXVirtualKeyboardService, IInterface(KBDService)) then
    begin
      edPassword.SetFocus;
      KBDService.ShowVirtualKeyboard(LoginViewForm);
    end;
end;

[Merkur]

Zu früh gefreut :(
Funktioniert unter Windows 8 Desktop aber nicht auf dem Tablet.
Dort erscheint keine Tastatur und das Programm lässt sich auch nicht mehr schließen.

[stahli]

Probleme beim Debugen!?

Ich habe diverse Probleme beim Debugen meines Frameworks.
Z.B. wird wenn eine Zelle eines Grids focussiert wird eine Neuzeichnung des Grids veranlasst.
In bestimmten Fällen gab es eine Fehlermeldung (Zugriff auf nil).
Eine Quelltextzeile wurde nicht angegeben.

Beim Debugen kam ich dann recht weit in´s System und dann wieder in DoEnter/DoExit meiner Zelle.
Dort wurde der Fehler durch das Zeichnen des übergeordneten Grids erzeugt.
Ok, das habe ich nun geändert.

Aber rätselhaft ist mir, warum der Debuger die Fehlerstelle nicht erkennt.
Auch Eurekalog 7 ist da scheinbar hilflos...

Kennt Ihr das Problem auch?

[DSCHUCH]

Das Problem hatten wir ja zuletzt häufiger hier.

Das Problem ist, das der Code auch auf NIL objekte ausgeführt wird, solange bis auf das Feld einer Klasse zugegriffen wird. Damit weiß der Debugger die eigentliche Fehlerzeile nicht, sondern nur die Zeile, wo das erste mal auf ein internes Feld einer Klasse zugegriffen wird.

Du muß von dieser Zeile ausgehend rückwärts den CallStack durchprüfen und Schauen/Testen/Überlegen, wo der Fehler eigentlich entstanden ist und wie weit der Code noch ausgeführt wurde, obwohl Objekte NIL sind.

[stahli]

Das komische ist, dass der Eintritt in meine Cell.DoEnter im CallStack gar nicht mehr zu sehen war. Irgendwie funktioniert der Debuger nicht wie bisher von der VCL gewohnt.
Ist etwas schwer zu beschreiben. Vielleicht hat auch mein System ein Problem, wenn Ihr das nicht bestätigen könnt ("Verwendung suchen" funktioniert auch nicht mehr seit einiger Zeit).

[stahli]

"Verschieben Formularweit"...

Ich ermögliche ein Verschieben der HeaderItems von meinem Gitter. Dragmode möchte ich in dem Fall nicht/ungern nutzen und löse das mit MouseDown und MouseMove.
(In gleicher Weise will ich die Breitenänderung durch anfassen am Rand ermöglichen.)
Solange ich über meinem gezogenen Header bin ist alles super (gelber Pfeil).

Wenn ich aber außerhalb des gezogenen HeaderItems gerate greift (natürlich) MouseMove nicht mehr.
Den benachbarten HeaderItems und deren Parent kann ich ja beibringen, dass Sie auf dieses "DragOver" reagieren (roter Pfeil). Das ist mir aber etwas zu umständlich.

Gibt es eine allgemeinere Lösung, dass generell auf das Ziehen reagiert wird egal über welchem Control die Maus gerade ist (Pfeile mit Fragezeichen)? Das soll aber (im FMX!) automatisch passieren, nicht irgendwie in Application-Ereignissen o.ä.
Eigentlich müsste MouseMove bestenfalls auch außerhalb des gezogenen HeaderItems weiter feuern.
Die Mausposition zum Formular habe ich beim Mausklick vor dem Ziehvorgang bereits ermittellt und könnte somit die Verschiebung immer über die Mausposition zum Formular feststellen.

Ich habe mal in den Splitter geschaut, da aber auf die Schnelle noch nichts passendes gefunden, wie man so etwas realisieren kann.

Weiß jemand Rat?