Focus-Problem bei Firemonkey

[jaenicke]

Das funktioniert, weil der Fokus tatsächlich erst nach dem Event gesetzt wird, ebenso wie die UI-Effekte usw.
Eine schöne Lösung ist das aber wohl nicht, denn wie die Folgefehler mit dem fehlenden Cursor zeigt ist das so nicht gedacht gewesen.

Leider kommt man da aber auch kaum heran. Die Prozedur SetFocusControl des Formulars (habs grad nicht mehr so genau im Kopf) ist z.B. natürlich wieder nicht virtuell. (Sonst wäre es ja zu einfach da etwas zu ändern... :roll:) Diese Designprobleme ziehen sich leider auch durch Firemonkey durch (das Problem gibt es ja in der VCL genauso). Immer nur das ist virtuell was gerade jemand an anderer Stelle gebraucht hat. An die Programmierer, die später damit arbeiten, wird offenbar weniger gedacht.

Eine Lösung:
SetFocusControl asynchron nach dem Ende der Prozedur aufrufen um den Fokus zurückzusetzen. In der VCL hätte ich mir dazu selbst eine Windows Message geschickt. In Firemonkey fällt mir gerade keine schöne Lösung dafür ein.

[RWarnecke]

Ich habe es jetzt nicht ausprobiert, aber was ist, wenn der Wert von Edit 1 erst im OnEnter von Edit 2 überprüft wird.

[eddie11]

Zitat:

Die Prozedur SetFocus oder so des Formulars (habs grad nicht mehr so genau im Kopf) ist z.B. natürlich wieder nicht virtuell.

Das war auch mein Ansatz aber wie gesagt, SetFocusControl (so heißt die Prozedur) ist leider nicht virtuell.

Zitat:

Ich habe es jetzt nicht ausprobiert, aber was ist, wenn der Wert von Edit 1 erst im OnEnter von Edit 2 überprüft wird.

Das wird der Weg sein, den ich gehen werde.
Da ich alle Forms von einer eigenen BasisForm erben lasse, kann ich ein eigenes Property "FocusedControl" einbauen. Dieses Property wird dann beim OnEnter eines Controls gesetzt. Im Setter der Property (in der Form) wird dann die EingabePrüfung für das zuvor aktiv gewesene Control durchgeführt.

[himitsu]

Wegen der UI-Efekte bräuchte man doch einfach nur ein Neuzeichnen des UI veranlassen. :gruebel:

Zitat:

Ich habe es jetzt nicht ausprobiert, aber was ist, wenn der Wert von Edit 1 erst im OnEnter von Edit 2 überprüft wird.

Ein Problem dabei ist ja, daß man dann anstatt in einem OnExit man nun in allen OnEnter, jeder einzelnen Komponente auf der Form prüfen müßte und das dann womöglich auch noch abhängig von der Komponente, welche davor fokusiert war,
denn man kann ja von Edit1 nicht nur zu Edit2 wechseln. (rückwärts tabben und dann gibt's och noch die Maus)

Da muß Emba unbedingt noch etwas nacharbeiten, oder sie bieten ein OnFocusChange-Event in der Form an, wo man die alte und neue Komonente erfährt und wo man z.B. ein Accept-Flag setzen kann.



In der Zwischenzeit könnte man sich höchstens noch eine SetFocus-Prozedur schreiben, welche den Fokus setzt, die "fehlenden" UI-Ereignisse auslöst und dann mit Abort abbricht.

[eddie11]

also nach einer ziemlich langen Rumprobiererei bin ich zu dem Schluss gekommen, dass das so nicht funzen kann. Es scheint ziemlich aussichtslos, eine vernünftige Eingabe-Validierung direkt nach der Eingabe zu machen - das ist aber am Besten füe den Anwender!

Dazu kommt noch, dass Memory-Leaks erzeugt werden, wenn man im OnExit oder OnEnter eines Controls den Fokus auf ein anderes Control setzt...

Aber mal ne andere Frage:

Wie macht Ihr das denn so mit der Eingabe-Validierung?

[jaenicke]

Ich markiere in Rot oder mit einem Hinweisfähnchen inkl. kurzer Erklärung (je nach GUI), lasse aber in der Regel den Fokus unberührt um den Arbeitsfluss nicht unnötig zu stören. So sieht der User, dass etwas nicht in Ordnung ist, kann aber erst einmal weitermachen oder direkt zurück und korrigieren, ganz nach Wunsch.

Die einzige wirklich saubere Lösung für dein Vorhaben wäre wie schon geschrieben den Fokus nach dem Event zurückzusetzen, wenn SetFocusControl schon durch ist. Wie das bei Firemonkey am besten geht, weiß ich nicht.

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1178366)

Ich markiere in Rot oder mit einem Hinweisfähnchen inkl. kurzer Erklärung (je nach GUI), lasse aber in der Regel den Fokus unberührt um den Arbeitsfluss nicht unnötig zu stören. So sieht der User, dass etwas nicht in Ordnung ist, kann aber erst einmal weitermachen oder direkt zurück und korrigieren, ganz nach Wunsch.

So mache ich das bei meiner Software auch. Grade wenn "blind" eingegeben wird, ist es ärgerlich wenn man immer im gleichen Feld hängen bleibt. Und bei Eingabe großen Datenmengen kommt die blinde Eingabe oft vor.

[himitsu]

Bei FM kann man ja nun ganz leicht einen knallroten Schein um die betreffenden Eingabeelemente machen.

[eddie11]

ok, das mit dem Markieren gefällt mir gut, das werde ich dann auch so machen. Die endgültige Prüfung muss dann bei Drücken von "Ok" oder sonstiger weiterer Verarbeitung nochmals alles Validieren und dann ggf. einen entsprechenden Hinweis bringen. Allerdings hätte ich es lieber, wenn direkt nach der Eingabe ein Hinweis käme ohne den es nicht weiter geht. Oft sind die Eingaben einzelner Felder voneinander abhängig (z.B. Postleitzahl, Ort und Straßen) - aber wenns nicht mit überschaubarem Aufwand hinzukriegen ist...

[jaenicke]

Zur Not kannst du nen Timer draufsetzen, der auf 1 Millisekunde gestellt ist, und dann direkt den Fokus zurücksetzt. Schön ist das aber nicht.

Ich habe schon probiert TThread.Queue zu benutzen, aber das ging auch nicht.