Setfocus auf dbgrid

[Perlsau]

Wo genau setzt du denn deinen Fokus für das DBGrid? Ich würde das in deinem Fall mal in der Button-Ereignisbehandlung versuchen ...

[Luckner]

Aus einem Editfeld im Panel wird folgendes aufgerufen:

Delphi-Quellcode:

procedure TFrameAuftrag.JvEditKundennrsuchenKeyDown(Sender: TObject;
  var Key: Word; Shift: TShiftState);
begin
  if Key = VK_F10 then ButtonPanelSchliessen.Click;
end;

Dann im Button:

Delphi-Quellcode:

procedure TFrameAuftrag.ButtonPanelSchliessenClick(Sender: TObject);
begin
 DBGridAuftrag.SetFocus;
 PanelFilter.Visible := False;
 JvHTButtonSuchenFiltern.Visible := True;
end;

[Perlsau]

Was passiert, wenn du das Setzen des DBGrid-Fokus ans Ende stellst, d.h. zuletzt ausführst? Welche Delphi-Version verwendest du eigentlich?

[stahli]

Wird denn ButtonPanelSchliessenClick auch ausgeführt?

Versuche dann mal folgendes:

Delphi-Quellcode:

procedure TFrameAuftrag.ButtonPanelSchliessenClick(Sender: TObject);
 begin
  DBGridAuftrag.SetFocus;
  // PanelFilter.Visible := False;
  // JvHTButtonSuchenFiltern.Visible := True;
 end;

Es ist denkbar, dass Dir hier ein Zeitverhalten der VCL in die Quere kommt. Es KÖNNTE SEIN, dass der Focus noch nicht wirklich umgesetzt wurde und Dein Edit durch Ausschalten des Panels "verschwindet". Dann würde der Parent den Focus erhalten.

Wenn das das Problem wäre, dann vielleicht einfach den Focus zuletzt zuweisen:

Delphi-Quellcode:

procedure TFrameAuftrag.ButtonPanelSchliessenClick(Sender: TObject);
 begin
  PanelFilter.Visible := False;
  JvHTButtonSuchenFiltern.Visible := True;
  DBGridAuftrag.SetFocus;
 end;

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


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

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

[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