FireMonkey Sammelthread

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