FormKeyPress durch ComboBox doppelten Aufruf verhindern

[Nixsager]

Hi

Ich hoffe um Erklärung und Hilfe zu folgendem Problem.

Wenn ich ein meinem Formular eine ComboBox (hat den Fokus) ausgewählt habe, wird die FormKeyPress-Prozedur doppelt aufgerufen.

1. Das doppelte Aufrufen der Prozedur kann man ja mit 'Key := #' verhindern.
Tipp-Quelle: https://www.delphipraxis.net/172826-...ml#post1200461
Aber wieso kann man damit das doppelte Aufrufen der Prozedur verhindern?
Und es setzt ja die Variabel 'Key' ja zurück, so das es nichts bringt wenn man sie danach auslesen will.

2. Wie kann ich das Problem besser lösen?

Gruß vom Nixsager

[Whookie]

Das FormKeyPress-Ereignis wird niemals "doppelt" aufgerufen, damit es überhaupt aufgerufen wird muss Form.KeyPreview := TRUE gesetzt werden (im Objektinspektor, oder per Code).

Nur in diesem Fall bekommt man in FormKeyPress vor der ComboBox die Gelegenheit zu entscheiden, ob eine eigene Verarbeitung in Frage kommt bzw. eine spezielle Reaktion auf die Taste erwünscht ist. Auch kann man hier Entscheiden ob sie eventuell nicht an die ComboBox übergeben werden soll (Key := #0).

Folgendes (ansonsten sinnbefreites) Beispiel zeigt dir ein paar Möglichkeiten (auf der Form befinden sich ein Memo, eine ComboBox und eine Checkbox):

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin
  KeyPreview := TRUE; 
//  KeyPreview := FALSE;
end;

procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);
begin
  //
  Memo1.Lines.Add(Format('Key: %s', [Key]));


  if UpCase(Key)='C' then
  begin
    CheckBox1.Checked := Not CheckBox1.Checked;
  end;

  if Key='a' then
  begin
    Key := #0;
    Memo1.Lines.Add('No lower case ''a'' at all!');
  end;

  if Key='v' then
  begin
    Key := UpCase(Key);
  end;
end;

[DP-Maintenance]

Dieses Thema wurde am "26. Jan 2019, 11:59 Uhr" von "Luckie" aus dem Forum "Object-Pascal / Delphi-Language" in das Forum "GUI-Design mit VCL / FireMonkey / Common Controls" verschoben.

[Nixsager]

Vielleicht hast du mich nicht verstanden, oder ich dich nicht.

Das Problem taucht auf wenn bei ComboBox.Style was anderes ausgewählt ist als csDropDown oder csSimple.

Ich habe mal ein Beispiel angehängt.
In dem Beispiel wird eine Variabel mit dem Startwert von 1 beim drücken der Taste [s] mit 2 multipliziert und beim drücken der Taste [a] durch 2 dividiert.
Zusätzlich wird eine Kontrollvariabel Startwert von 1 beim drücken einer Taste mit 2 multipliziert.

Hat man die ComboBox ausgewählt, wird anstatt mit 2 multipliziert bzw. durch 2 dividiert, mit 4 multipliziert bzw. durch 4 dividiert.
Was darauf schließen lässt, das die FormKeyPress-Prozedur doppelt aufgerufen wird.

[Whookie]

Im konkreten Fall kommt es darauf an, aus welchem Kontext der Tastendruck erfolgt.

Ist das ComboBox-Edit-Control aktiv (z.B.:

Delphi-Quellcode:

Style := cdDropDown

), wird der Tastendruck über

Delphi-Quellcode:

TCustomCombo.ComboWndProc

(WM_CHAR) empfangen. An dieser Stelle wird die DoKeyPress-Methode aufgerufen und darüber das OnKeyPress-Ereignis ausgelöst. Am Ende dieser Fensterprozedur (ComboWndProc) wird die Verarbeitung direkt an Windows übergeben (CallWindowProc).

Ist das ComboBox-Edit-Control nicht aktiv (z.B.:

Delphi-Quellcode:

Style := csDropDownList

) dann wird der Tastendruck über

Delphi-Quellcode:

TCustomCombo.WndProc

(WM_CHAR) empfangen. Auch hier wird wieder das OnKeyPress-Ereignis ausgelöst. Am Ende der Fensterprozedur wird aber die Fensterprozedur des Vorgängers aufgerufen (

Delphi-Quellcode:

inherited WndProc

) und dadurch dann

Delphi-Quellcode:

TWinControl.WMChar

ausgelöst, wodurch der zweite OnKeyPress - Aufruf erfolgt.

Verhindern kann man das nur indem man über

Delphi-Quellcode:

Key := #0

die Verarbeitung der Taste als abgeschlossen markiert.

Je nachdem, was du erreichen willst ist

Delphi-Quellcode:

Form.KeyPreview

nicht die geeignete Methode, oft ist es vernünftiger TAction zu verwenden und dort einen Shortcut einzustellen...

[Nixsager]

Danke für die gute und ausführliche Erklärung, auch wenn ich sie nicht ganz verstanden habe.

Aber ein Paar Fragen habe ich noch.

1. Ist es nicht ein Fehler, das das OnKeyPress-Ereignis des Fensters von der ComboBox ausgeführt wird?
Die ComboBox hat doch selber das Ereignis.
Und das das OnKeyPress-Ereignis des Fensters ausgeführt wird ist ja kein Fehler, denn dafür habe ich ja die KeyPreview aktiviert.

Was ich noch herausgefunde habe:
Sind Einträge in der ComboBox vorhanden die mit dem Buchstaben der gedrückten Taste anfangen, wird das OnKeyPress-Ereignis des Fensters nicht ausgeführt.

2. Wieso verhindert

Delphi-Quellcode:

Key := 0;

die doppelte Ausführung?
Es ist ja wie ein spezielles

Delphi-Quellcode:

Exit;

.
Denn die Prozedur wird ja direkt verlassen.

3. Wo ist der Unterschied zwischen DoKeyPress und OnKeyPres?

[Whookie]

Grundsätzlich sind Windows-Controls auch nur (spezialisierte) Fenster, erhalten also direkt alle Botschaften vom System (Windows). Ein Tastendruck gehört da auch dazu und im Normalfall wird er auch vom Control direkt verarbeitet.

Damit das OnKeyPreview-Event überhaupt funktionieren kann, benachrichtigt also das Control (in deinem Fall die ComboBox) das Formular über das empfangene Zeichen. Dazu ruft die ComboBox ihre DoKeyPress-Methode auf und von hier aus wird das OnKeyPreview-Ereignis des Formulars aufgerufen. Setzt du darin Key := #0 bricht das Control bei der Rückkehr aus dem Event die Verarbeitung ab.

Damit stellt sich eigentlich nur die Frage, ob der zweifache Aufruf ein Bug ist und ich neige dazu das so zu sehen. Allerdings ist das ganze System komplex (viele verschiedene Funktionen benötigen die Information) und auf den ersten Blick ist das wohl nicht so einfach zu reparieren. Ich hab jetzt im Emba-Bugtracker nicht nachgesehen ob das verhalten bereits gemeldet wurde, man könnte das aber durchaus machen.

Zu 3:
DoKeyPress ist eine Methode (implementiert in TWinControl) die aufgerufen wird, wenn eine WM_CHAR - Botschaft empfangen wurde. Innerhalb von DoKeyPress wird entschieden ob das OnKeyPreview-Ereignis des Formulars auf dem das Control liegt ausgelöst werden muss/soll.