Trapping Return - Serious problem ?

Post your Gambas programming questions here.
Doctor Watson
Posts: 58
Joined: Wednesday 22nd August 2018 7:55am

Trapping Return - Serious problem ?

Post by Doctor Watson » Tuesday 13th April 2021 2:54pm

I need to ‘trap’ the Return, F1 and other function keys, but that doesn’t seem to work. Or I’m doing something wrong and I don’t see it.
What follows here comes straight from the Gambas help that pops up when you’re typing code.
But there may be a surprise ...
So I made the following test on an otherwise empty form.
- Put Button1 on a Form
- Added Gambas class file (as copied from Gambas help)
PUBLIC SUB Button1_KeyPress()
  IF Key.Alt THEN
    Button1.Text = " True " & CString(Time)
  ELSE
    Button1.Text = " False " & CString(Time)
  ENDIF
END
When I run this, it just seems to ignore the IF condition.
Whatever key I hit – be it a function key, numeric, abc – it jumps to the 'False' text.
But when I hit the Alt key, it STILL reports false. So it seems it doesn’t recognize the Alt key.
I tried this for other function keys – Enter, F1, Esc, … - with the same result.
Tried it with a ValueBox. Same error.

Surprise ! When I change Key.Alt to Key.AltKey, whatever key I hit on my keyboard suddenly returns TRUE !

The on-screen help gives a warning : “Keys may have functions assigned to them by OS or other programs; you could close/... your program/other programs/system.”
So I made sure no other programmes were running. Even re-booted my computer a couple of times to make sure. Still the same result.

Any ideas? This is essential for my programme to function.
Old african saying:
You eat an elephant one small bite at a time.

User avatar
PJBlack
Posts: 131
Joined: Tuesday 09th June 2020 10:26pm
Location: Florstadt, Hessen, Germany

Re: Trapping Return - Serious problem ?

Post by PJBlack » Tuesday 13th April 2021 4:48pm

Public Sub Form_KeyPress()
    ' KeyPress with Alt Key event will often pass through to this Form event.

    Dim altSet As Boolean

    Try altSet = Key.Alt
    altSet = IIf( Error , False, altSet)
    If altSet Then
        Debug CString(Time) & " True: Alt key is being held down"
    Else
        Debug CString(Time) & " False: Alt key was not held down"
    Endif

End

Doctor Watson
Posts: 58
Joined: Wednesday 22nd August 2018 7:55am

Re: Trapping Return - Serious problem ?

Post by Doctor Watson » Wednesday 14th April 2021 2:11am

Hi PJBlack
I tried your code - deleted the useless Cstring(Time)
Unfortunately the same strange things occur.
When pressing Alt or any other key, console indicates “Test.Form_KeyPress.22: False: Alt key was not held down”.
I then changed the code to test other function keys. And here’s the strange part : whichever key I try, the result is always the same. With some keys the result is False, with others it’s True.
Then I noticed something : when changing the Key.[Name] the list of available keynames is shown.
They are preceded by a blue or red dot.
When I try a blue-dotted one, like Key.Alt, Key.Shift, the result is False.
When choosing a red-dotted one, like Key.Return, Key.F1, the result is True.
And, as I said, whichever key on the keyboard I press.
There are even KeyNames that don't seem to exist, such as AltGrKey.
I haven’t the foggiest idea of what those red and blue dots stand for, but could we be looking at a bug?
Old african saying:
You eat an elephant one small bite at a time.

User avatar
stevedee
Posts: 429
Joined: Monday 20th March 2017 6:06pm

Re: Trapping Return - Serious problem ?

Post by stevedee » Wednesday 14th April 2021 7:05am

Doctor Watson wrote:
Wednesday 14th April 2021 2:11am
...Then I noticed something : when changing the Key.[Name] the list of available keynames is shown.
They are preceded by a blue or red dot.
When I try a blue-dotted one, like Key.Alt, Key.Shift, the result is False.
When choosing a red-dotted one, like Key.Return, Key.F1, the result is True.
And, as I said, whichever key on the keyboard I press.
There are even KeyNames that don't seem to exist, such as AltGrKey.
I haven’t the foggiest idea of what those red and blue dots stand for, but could we be looking at a bug?
Take a close look at the red & blue list of options and you will notice that the reds are Constants and the blues are Properties.
Key_help.png
Key_help.png (60.96 KiB) Viewed 357 times
On my UK laptop keyboard the <AltGr> key is on the right-hand side of the spacebar. What kind of keyboard layout do you have?

You cannot use Key.AltKey in your code example because it returns an Integer.

Your basic code moved to Form_KeyPress() seems to work for me:-
Public Sub Form_KeyPress()

  If Key.Alt Then
    Me.Text = " True " & CString(Time)
  Else
    Me.Text = " False " & CString(Time)
  Endif
End
If your code is part of a bigger project, just do a quick test project with the minimum code to see if it works. Step through the code using the <F8> key to make sure it is not failing for some other reason.

You could also use this code to check that keys are returning the correct values:-
Public Sub Form_KeyPress()
Dim varKey As Variant

  varKey = Key.Code
  Me.Caption = "Last key: " & varKey

End
...but take note of the warning message in the .Code help screen:-
Key_help_warning.png
Key_help_warning.png (48.67 KiB) Viewed 357 times
...however, this may still provide some useful diagnostic information.

User avatar
grayghost4
Posts: 93
Joined: Wednesday 05th December 2018 5:00am
Location: Marengo, illinois usa

Re: Trapping Return - Serious problem ?

Post by grayghost4 » Wednesday 14th April 2021 1:25pm

maybe this will help you :
Public Sub Form_KeyPress()   ' or Button1_KeyPress()
 
 If Key.Code = Key.AltKey Then
    Button1.Text = " True " & CString(Time)
  Else
    Button1.Text = " False " & CString(Time)
  Endif  
  Me.Caption = "Last key: " & Key.Code
  
 End
or this :
Public Sub Form_KeyPress()
 
   Select Case Key.Code
     
     Case Key.Return
       Button1.TEXT = "RETURN "
       
     Case Key.AltKey
      Button1.Text = " ALT " 
   End Select
   Me.Caption = "Last key: " & Key.Code
  
End
Last edited by grayghost4 on Wednesday 14th April 2021 3:34pm, edited 1 time in total.

User avatar
cogier
Site Admin
Posts: 690
Joined: Wednesday 21st September 2016 2:22pm
Location: Guernsey, Channel Islands

Re: Trapping Return - Serious problem ?

Post by cogier » Wednesday 14th April 2021 3:24pm

I have been trying to work out exactly what you are after without success, however, I notice the line PUBLIC SUB Button1_KeyPress(). If you want the key to be activated by the Return key then set the Button Property Default to True. You can also activate the Button with the Esc key by setting the Button Property Cancel to True.

Another simple way to set a shortcut for the Button is to add an & to the Button Text Property. e.g. Button1.Text = "&Click me!" will underline the 'C' and allow you to use the shortcut Alt+C to activate the key.

If all of us are missing the point can you give us an idea what the program, and you hope to achieve.

Doctor Watson
Posts: 58
Joined: Wednesday 22nd August 2018 7:55am

Re: Trapping Return - Serious problem ?

Post by Doctor Watson » Wednesday 14th April 2021 3:33pm

Hurray! Grayghhost4,

That does the trick indeed. That is, for the ‘red-dotted’ keys in the list, those returning an Integer, as mentioned by Steve. And those are just the ones I need.
How simple can it be, but it still doesn’t explain why some different approaches won’t work.

Steve, the AltGrKey is, just as on your keyboard first right of the space bar. It’s a Logitech and it’s AltGr works perfectly. Just tested it with Grayghhost4’s code and still gives the error : “Unknown symbol ‘AltGrKey ‘in class ‘Key’ in Form1”.
I’m going to do a test run on all function keys to find out if there are any more surprises.
Old african saying:
You eat an elephant one small bite at a time.

Doctor Watson
Posts: 58
Joined: Wednesday 22nd August 2018 7:55am

Re: Trapping Return - Serious problem ?

Post by Doctor Watson » Wednesday 14th April 2021 3:47pm

Hi Steve and Cogier
Our posts just have come through together.
I will test what you suggest, but as I just wrote, Grayghhost4’s solution seems to work fine.
The mayor keys I need throughout in my program are the F1, used to enter a help screen or pop-up, and the Return key.
And here’s what perhaps started this all : on my keyboard, the ‘Return’ key is named ‘Enter’.
If I find something else, I’ll let you know.
Old african saying:
You eat an elephant one small bite at a time.

User avatar
cogier
Site Admin
Posts: 690
Joined: Wednesday 21st September 2016 2:22pm
Location: Guernsey, Channel Islands

Re: Trapping Return - Serious problem ?

Post by cogier » Wednesday 14th April 2021 4:37pm

on my keyboard, the ‘Return’ key is named ‘Enter’.
The 'Return' key (1) is on the main keyboard and the 'Enter' (2) key is on the numeric keyboard.

Image

User avatar
BruceSteers
Posts: 473
Joined: Thursday 23rd July 2020 5:20pm

Re: Trapping Return - Serious problem ?

Post by BruceSteers » Wednesday 14th April 2021 11:07pm

AltGrKey does not work. (it broken in gambas)

the right alt key is actually called ISO_Level3_Shift (the Windows keys are called Super)

It's a pain dealing with it

it's hex value with gtk will be 0xfe03 (as per keysymdef.h)
If Key.Code = &hfe03&

with qt it's integer value is 16781571 (annoyingly a different value than gtk)
If Key.Code = 16781571

and then there's wayland that gambas key.class (and Desktop.SendKeys) do not support well.

Gambas Key.class has limitations with the right AltGr key and also it cannot define between left or right Alt/Shift/Ctrl keys
You can do it by manually checking out the key values
Ie.

Public Sub Form_KeyPress()
Print Str(Key.Code)
End

Run that and hit the key you want to register and make a note of it's code then you can test for that value.

Key codes are not so well supported as keyboards vary throughout the world and gui toolkits like gtk/qt/wayland/etc all vary the codes they give.
Wishing well
Bruce

If at first you don't succeed , try it differently.

Post Reply