Setfocus auf dbgrid

[Perlsau]

Zitat von stahli:

Da die VCL solche Anweisungen verzögert durch Nachrichtenverarbeitungen abarbeitet muss man mit solchen Effekten rechnen.

Eigentlich kann ich mir nicht vorstellen, daß die Codezeilen nicht der Reihe nach ausgeführt werden. Ich glaube vielmehr, daß durch das Unsichtbarmachen des einen und das Sichtbarmachen des anderen der Fokus gesetzt wird, was auch immer das für visuelle Komponenten sind:

Delphi-Quellcode:

 PanelFilter.Visible := False;
 JvHTButtonSuchenFiltern.Visible := True;

Zitat von stahli:

EDIT: Oups, kein roter Kasten, aber Perlsau ist wohl auf der gleichen Spur...

Genau deshalb bin ich mir ziemlich sicher, daß das Setzen des Fokus ans Ende der Befehlsliste gehört. Das war schon mein Gedanke, als ich den TE oben fragte:

Zitat:

vielleicht wird ja noch was aufgerufen nach dem DBGrid.SetFocus, das den Fokus wieder verändert ... ?

.

Zitat von Luckner:

Die Lösung ist: Key:=0; Jetzt funktioniert es.

Echt? Kann ich mir kaum vorstellen ... wie sieht dein Code denn jetzt aus?

Ach ja, bevor ich's wieder vergesse: Welche Delphi-Version setzt du ein?

[stahli]

Ok, Problem ist ja gelöst, dennoch ein Satz zu Perlsaus Frage:

Wenn DBGrid konkret den Fokus hat, dürfte es ja egal sein, ob ein anderes Panel ausgeblendet wird. In meinem Framework bin ich mit ähnlichen Abläufen aber einige Male auf die Nase gefallen - und bei verschiedenen Delphi- bzw- Windows-Versionen auch unterschiedlich.
Man kann auf jeden Fall nicht davon ausgegen, dass alle VCL-Ereignisse immer und überall 1:1 chronologisch nacheinander abgearbeitet werden.

Die Codezeilen werden natürlich nacheinander abgearbeitet, aber wenn nur Nachrichten verschickt werden kann man nie sicher sein, wann diese "beim Empfänger" verarbeitet werden. Bei schnellen Abläufen kann dann mal eine erwartete Reihenfolge durcheinander kommen.

Ein konkretes (ähnlich gelagertes) Problem hatte ich, wenn ich ein focusiertes Control gelöscht habe und zuvor ein anderes focusiert habe. Windows wollte dann unbedingt das gelöschte nochmal neu zeichnen, aber das existierte dann ja nicht mehr. Gelöst habe ich das indem ich das zu löschende Control erst mal unsichtbar gemacht und erst später gelöscht habe.

Dass die Lösung hier in der Key-Behandlung lag ist beruhigend. Aber Zusammenhänge wie von mir angesprochen sollte man mit als mögliche Problemursache beachten.

[Perlsau]

Okay, das mit den verzögerten Messages kann ich zwar theoretisch nachvollziehen, hab's aber noch nicht erlebt bzw. hab keinen Schimmer, wie man das reproduzieren könnte. Dagegen erlebe ich des Öfteren, daß ein Umstellen der Befehlsreihenfolge ein Fehlverhalten beseitigen kann. Z.B. hatte ich kürzlich ein ähnliches Problem: Wenn ich ein DB-Edit, das den Fokus hatte und das auf eine Tabelle zeigte, die sich im Edit- oder Insert-Modus befand, auf ReadOnly := True setzte, wurde der geänderte Wert beim Tabelle.Post nicht übernommen. Bemerkt hatte ich das dadurch, daß ein Auslösen von Tabelle.Post via Buttonklick dazu führte, den Wert zu übernehmen, via Menüklick dagegen nicht. Beide Klicks führten zur selben Ereignisbehandlung einer TActionList. Der Unterschied bestand lediglich darin, daß beim Klick auf den Button der Fokus vom DBEdit weg war, bevor ich dieses Edit auf ReadOnly setzte, beim Klick via Menü jedoch weiterhin den Fokus behielt. Die Lösung bestand darin, den Fokus in der Ereignisbehandlung auf den Button zu setzen und gut war. Natürlich hätte ich auch die Reihenfolge in der Post-Methode ändern können: Erst posten und dann DBEdit.ReadOnly := True. Doch das hätte mein Programmkonzept völlig über den Haufen geworfen, was jetzt aber zu weit führen würde.

Zitat von stahli:

Wenn DBGrid konkret den Fokus hat, dürfte es ja egal sein, ob ein anderes Panel ausgeblendet wird.

Ich dachte mal, wenn der TE in seiner DBEdit-Ereignisbehandlung (KeyDown) die ButtonPanelSchliessen-Ereignisbehandlung aufruft (ist eigentlich schlechter Stil, das sollte eine private Methode sein, die von Key- und Button-Ereignisbehandlung gleichermaßen aufgerufen wird), könnte da nicht der Fokus auf dem DBEdit verbleiben? Denn schließlich folgt nach dem KeyDown noch das KeyUp, das ja ebenfalls vom Benutzer ausgelöst wird und den Fokus womöglich wieder an das DBEdit zurückgibt. Oder gehört das KeyUp dann dem DBGrid, wenn das den Fokus hat? Mir ist auf jeden Fall nicht so recht klar, wieso ein leeren des Tastaturpuffers im KeyDown des DBEdit (Key = #0) das Problem löst ...

[stahli]

Wir schweifen etwas ab, aber noch kurz:

Die VCL hat gewissermaßen ein Eigenleben, das sich auch mal ändern kann. Eigene Logiken davon abhängig zu machen, kann unerwartete Schwierigkeiten bereiten.
Hinzu kommt, dass die Controls in sich öfters nicht so arbeiten, wie man es erwarten sollte (http://www.delphipraxis.net/85385-tr...kt-falsch.html).
Das sollte man nur im Auge behalten.

Das vorliegende Key-Problem ist wohl, dass F10 eine Menüfunktion aufruft. Wenn Key nicht "neutralisiert" wird, macht Windows das noch, nachdem die Anwendung schon mit der Bearbeitung fertig ist.

[Perlsau]

Zitat von stahli:

Das vorliegende Key-Problem ist wohl, dass F10 eine Menüfunktion aufruft. Wenn Key nicht "neutralisiert" wird, macht Windows das noch, nachdem die Anwendung schon mit der Bearbeitung fertig ist.

Ach ja, ich vergaß: F10 ist ja die universelle Windows-Taste für den Aufruf des jeweiligen Hauptmenüs: Schlechte Wahl für eine Anwendung ...

Für dein DBRadioGroup hätte ich einfach TJvDBRadioPanel aus den Jedis genommen ...

[himitsu]

Zitat von Perlsau:

Zitat von Luckner:

Die Lösung ist: Key:=0; Jetzt funktioniert es.

Echt? Kann ich mir kaum vorstellen ... wie sieht dein Code denn jetzt aus?

Auf F10 reagiert z.B. das Hauptmenü, womit dann nach dem Verlassen der Eventmethode noch anderer Code auf das VK_F10 ragiert und irgendwas macht.


PS: Den schönsten Spaß hat man, wenn einige Ereignisse im OnKeyDown verarbeitet werden und Andere im OnKeyUp.

Ein gutes Beispiel hatte ich da auch mal, so wurde im OnKeyDown per F2 das aktuelle ShowModal-Fenster geschlossen,
während das übergeordnete Fenster im OnKeyUp per F2 eine neue Instanz des Fenster öffnete.
- F2 rein und alles ist OK
- per F2 wieder raus ging nicht, da es gleich wieder rein ging, weil das eine Fenster sich im Down ausblendete und das Up dann im anderen Fenster landete.
> beides gleichermaßen im Up ODER im Down ausgeführt, hätte keine Probleme bereitet

Oder wie hier:
Mehrere Stellen verarbeiten das selbe Tastenereignis und man wundert sich dann, wenn Mehreres passiert oder Einiges nicht richtig.

[Perlsau]

Genau dafür gibt's den Spruch: Verarschen kann ich mich alleine
Daß das wunderbar klappt, hat wohl schon jeder einmal erleben dürfen

[Luckner]

Hallo Perlsau, himitsu,

Meine Delphi-Version ist 7 Pro. Folgendes Problem noch, auf das, so glaube ich, gerade himitsu darauf hingewiesen hat. Habe versucht einige Funktionen ebenfalls in einem anderem Frame mit den F-Tasten zu steuern. Es funktioniert nicht, weil im Tastaturpuffer jetzt die Funktionen der F-Tasten aus dem vorherigen Frame noch hinterlegt sind und in einem weiterem Frame nicht funktionieren bzw. Mist machen. Kann ich, wenn ich ein Frame verlasse, den gesamten Tastaturpuffer zurücksetzen? Mit dem key := 0 funktioniert auch das Bewegen mit den Pfeiltasten im DB-Grid nicht mehr. Aber das werde ich noch gesondert überprüfen.

[himitsu]

Ich hoffe du setzt das nur dann auf 0, wenn du darin etwas gemacht hast (z.B. nur bei deinem VK_F10) und nicht immer auch für alle anderen Ereignisse.

PS: Man sollte am Besten auch unbedingt immer die kompletten ShiftStates prüfen.
Also nicht mit ... IN Shift , sondern mit Shift = [...] , auch und vorallem wenn man keine dieser Tasten verwendet.
F10 ist nunmal kein Strg+F10 usw.

Delphi-Quellcode:

if (Key = VK_F10) and (Shift = []) then begin
  ...
  Key := 0;
end;

[Luckner]

Danke himitsu,
der Tipp mit key:=0 war richtig. Hatte Das an der falsche Stelle gesetzt. Jetzt habe ich das Problem, das z.B. die F2-Taste in einem weiterem Frame eine andere Funktion haben sollte. Leider wird die Funktion aus dem vorherigem Frame aufgerufen. Da holft das Setzen key := 0 nicht. Irgendwie müsste man den speicher löschen. Aber wie?