TEdit on GTK2 strange input behavior

[TurboRascal]

I was playing with limiting TEdit input to numbers only, and used some of the code which TCustomSpinEdit uses to block non-numeric input, like this (btw. I like the decimal separator part):

Code: Pascal  [Select][+][-]

1.  
2. procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: char);
3. begin  
4.   if (Key in ['.',',']) then Key := DefaultFormatSettings.Decimalseparator;
5.   if not (Key in ['0'..'9', DefaultFormatSettings.DecimalSeparator, #8,#9]) then Key := #0;
6. end;
7.  

It worked as it should blocking non-numeric input (no C/P prevention yet included though), but to my surprise, when I pressed the letters with diacritics (čćžšđČĆŽŠĐ), they got printed! I've used some labels to show me the key codes and noticed that it doesn't show anything when I press those keys - it cannot be blocked because OnKeyPress handler doesn't  receive their keycodes at all. Then I've put a check in the OnKeyDown handler and noticed keycodes are received normally there, so I've blocked those keys there:

Code: Pascal  [Select][+][-]

1.   if (key >= 146) and (Key <= 150) then Key := 0;

This worked, but I wanted to block all "funny" characters, so I've changed it to

Code: Pascal  [Select][+][-]

1.   if key >127 then Key := 0;

However,once again I've found some unblocked characters: €¶ŧ←↓→øþ, which are produced by pressing AltGr key together with some letters in the upper row of the keyboard. This time I wasn't able to block it since even both the OnKeyPress received nothing and OnKeyDown receivedonly the keycodes of the keys I've pressed, as they normally are without AltGr.

It seems to me there is some bug here in the input routines, and even though I caught and worked around its first manifestation, but the other one is harder to handle.

So, my questions are, 1) should I file a bug (or is there one already open), and 2) how to best block the characters from the latter problem (perhaps I must check the content in OnChange handler)?

[ludob]

You should also test the ShiftState in OnKeyDown. This indicates the state of the ctrl, alt, shift keys when pressing a key. ALtGr is the same as Alt and results in ssAlt set in the ShiftState.  So for numeric characters Shift should be [] or [ssShift] depending on your keyboard. Things get complicated when you also want to accept numeric keypad entries.

[fabienwang]

I just tried this code:

  if (ssShift in Shift) or (ssCaps in Shift) then
    begin
      if not (Key in [VK_0, VK_1, VK_2, VK_3, VK_4, VK_5, VK_6, VK_7, VK_8, VK_9, VK_DELETE, VK_LEFT, VK_RIGHT, VK_HOME, VK_END, VK_BACK]) then
      Key := 0;
    end
    else
    begin
      if not (Key in [VK_NUMPAD0, VK_NUMPAD1, VK_NUMPAD2, VK_NUMPAD3, VK_NUMPAD4, VK_NUMPAD5, VK_NUMPAD6, VK_NUMPAD7, VK_NUMPAD8, VK_NUMPAD9, VK_DELETE, VK_LEFT, VK_RIGHT, VK_HOME, VK_END, VK_BACK]) then
      Key := 0;
    end;   

and it fails too. Typing fast chars makes them written (any)
also the CapsLock doesn't work with numbers over the letters (numpad works well).

[Bart]

These keys are handled in the OnUTF8KeyPress event.

There you can do something like (untested code)

Code: [Select]

  ...
  if Length(Key) > 1 then Key := '';
  ...

Any Key with length > 1 is an UTF8 sequence for a character not in the ASCII range.

Bart

[felipemdc]

So, my questions are, 1) should I file a bug (or is there one already open),

No, indeed characters might come from the input without a KeyUp/Down and this is expected. This also happens in Android when you use the virtual keyboard in some ways. Use UTF8KeyPress to complement, like Bart said.

[TurboRascal]

No, indeed characters might come from the input without a KeyUp/Down and this is expected. This also happens in Android when you use the virtual keyboard in some ways.

It seems LCL uses a similar mechanism even here, since regular OnKeyPress handler receives nothing when the mentioned characters are entered...

Use UTF8KeyPress to complement, like Bart said.

Yes that't it, thank you and Bart I wasn't aware there are two different keypress events since it doesn't exist in Windows....

I've tried with a similar check as before, "UTF8Key > 127" and it successfully filters out all the "funny" characters. So it seems I could've put all checks into this method, but since the event doesn't exist in Windows, I suppose that wouldn't work there, so it would break cross-platform compatibility. In fact, I wonder how does the Windows version of Lazarus deal with the event handler for the event it doesn't exist there... Will it break something, or perhaps strip the event handling code?