OpenEuphoria

2. Re: Hotkeys and win32lib apps

• Posted by Greg Haberek <ghaberek at gmail.com> Nov 23, 2004
• 581 views
• Last edited Nov 24, 2004

Here's a quote from w32Keys.e:

-- * VK_L* & VK_R* - left and right Alt, Ctrl and Shift virtual keys.
-- * Used only as parameters to GetAsyncKeyState() and GetKeyState().
-- * No other API or message will distinguish left and right keys in this way.
   , VK_LSHIFT	   = #A0
   , VK_RSHIFT	   = #A1
   , VK_LCONTROL	   = #A2
   , VK_RCONTROL	   = #A3
   , VK_LMENU	   = #A4
   , VK_RMENU	   = #A5

On 23 Nov 2004 19:29:09 +0100, Christian Cuvier
<christian.cuvier at agriculture.gouv.fr> wrote:
> 
> I wanted to trap Alt-Home to perform some procsing of my own in a Win32 app.
> Ok, just trap WM_KEYDOWN and look for VK_HOME and AltMask. Simple, and don't
> forget returnValue(0) so as to avoid the default processing of the Home key.
> 
> But this only works halfway. Using a french keyboard, this correctly
> identifies the right alt key, but not the left alt key. The latter works
> correctly however, as it activates menu items in the expected way.
> 
> Do I need to set up my own event loop so that it includes the
> TranslateAccelerator() API func so that I can trap these left alt-things?
> 
> CChris
> 
> 
> 
>

4. Re: Hotkeys and win32lib apps

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Nov 24, 2004
• 568 views
• Last edited Nov 25, 2004

Tone Škoda wrote:
> 
> You have to use WM_SYSKEYDOWN or WM_SYSCHAR.
> 

Thanks for the suggestion, which was quite good-looking, but it doesn't 
work. Even preempting Windows by catching WM_SYSKEYDOWN in a w32HEvent 
handler, the active window gets a handful of messages, but not that one 
(nor does it get WM_SYSKEYUP) when entering left alt-Home. Instead it gets
WM_KEYDOWN and VK_HOME, as if the left alt key was not being depressed.
And the key is alive since menus react correctly, ie left alt-f activates the
file menu.
The right alt key sends a WM_KEYDOWN and VK_MENU so I can trap it.

This looks like a non US keyboard issue. The handling of right alt that
I get matches what the docs describe in such a case.

Greg... my problem is that the keys behave differently, and NOT that I want to
 tell which one is being used :).

CChris

6. Re: Hotkeys and win32lib apps

• Posted by Derek Parnell <ddparnell at bigpond.com> Nov 25, 2004
• 564 views
• Last edited Nov 26, 2004

CChris wrote:
> 
> CChris wrote:
> > 
> > Tone Škoda wrote:
> > > 
> > > You have to use WM_SYSKEYDOWN or WM_SYSCHAR.
> > > 
> > 
> Sorry for the earlier message: I just was not listening to the right 
> channel (monitoring messages to main window rather than to the control with 
> focus)..
> 
> WM_SYSKEYDOWN is sent indeed. This makes me wonder if Derek doesn't want 
> to add this kind of support to fDoSYSKeys() ie WM_SYSKEYDOWN+VK_MENU would set
>
> the AltMask bit when processing the corresponding w32HKeyDown. Of course this
> proczssing must not take place if context code says no window has focus.

Okay, so keyboard events are not giving us the Alt key setting. This is
a mistake I've made. I'll fix it today. 
 
> Something weird however: instead of matching WM_SYSKEYUP, I get WM_NULL 
> (#0) messages with matching key codes in reverse. Is this documented 
> anywhere?

Not sure. I'll check this for you too.
-- 
Derek Parnell
Melbourne, Australia

8. Re: Hotkeys and win32lib apps

• Posted by "Christian Cuvier" <christian.cuvier at agriculture.gouv.fr> Nov 26, 2004
• 598 views

> Date: Fri, 26 Nov 2004 06:58:32 -0500
> From: "Wolf" <wolfritz at king.igs.net>
> Subject: Re: Hotkeys and win32lib apps
> 
> 
>>> Something weird however: instead of matching WM_SYSKEYUP, I get ...
> 
> 
> You're reading 'while-key-is-down' messages, which also include a
> repeat-count, scan-codes, previous-key-state, etc., in various bits of lParam.
> 

Sure. But at some point there should be some WM_SYSKEYUP, as my fingers
eventually leave the keyboard. And there's none sent either to the control or
to its parent. Or shouldn't there?

By "sent" I mean caught by a w32HEvent. Perhaps there's some filtering before
that. And this is a problem as, because of those repeat counts etc, I'd better
dealing with one WM_SYSKEYUP (or two, as VK_MENU and the alted key are both
released). If I can't trust WM_SYSKEYUP, I have to look for the previous key
state in bit 30 of lparam so as to act on the first message only (this works, 
but less elegantlly). All right, I already have to look for bit 29 to check if
it's really an alt-something...

CChris