wParam for Ctrl-F and F2
John Martens
and the use of Ctrl key in a Dispatch
oEvent:Message == WM_HELP
GetKeyState( VK_SHIFT )
GetKeyState( VK_CONTROL )
How do I detect Ctrl-F and also F2 ?
It must be simple but the VO Help reffers to Win SDK and there I cannot
find a page with all the oEvent:wParam or oEvent:Message codes.
John
Malcolm Gray
If I want to know about particular window messages I generally go to MSDN,
it documents all the official messages, and even groups then in a pretty
logical way.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/messages/wm_help.asp
seems to be one main page in the win SDK on WM_HELP for example.
Geoff Schaller
Trapping F1 Help is easy but its best to do it in an App:BeforeDispatch:
DO CASE
CASE uMsg = 0x0000004D
// extract out this message to launch the help process
// SELF:ProcessHelp(Event{hWnd, uMsg, wParam,
lParam,GetObjectByHandle(hWnd)})
RETURN FALSE
CASE uMsg = WM_KEYUP .and. wParam = VK_F1
// ignore it
SELF:ProcessHelp(Event{hWnd, uMsg, wParam,
lParam,GetObjectByHandle(hWnd)})
RETURN FALSE
ENDCASE
F2 is trivial - you can get it in any edit control dispatch with
oEvent:Message as WM_KEYDOWN or WM_KEYUP and oEvent:wParam = VK_F2
To detect shift and or Ctrl is also reasonably straightforward with:
FUNCTION ALT_ON () AS LOGIC STRICT
// if Left/Right required, use VK_LMENU and VK_RMENU
RETURN LOGIC(_CAST, _And(GetKeyState(VK_MENU), SHORT(_CAST, 0x8000)))
FUNCTION CTRL_ON () AS LOGIC STRICT
// if Left/Right required, use VK_LCONTROL and VK_RCONTROL
RETURN LOGIC(_CAST, _And(GetKeyState(VK_CONTROL), SHORT(_CAST, 0x8000)))
FUNCTION SHIFT_ON() AS LOGIC STRICT
// if Left/Right required, use VK_LSHIFT and VK_RSHIFT
RETURN LOGIC(_CAST, _And(GetKeyState(VK_SHIFT), SHORT(_CAST, 0x8000)))
HTH
Geoff
"John Martens" <CA...@TennisHulp.info> wrote in message
news:CA...@TennisHulp.info:
John Martens
Geoff,
Thanks for the answer. I now found the Win SDK page with all the VK_* in it.
I tried to use the shown code on (data)dialogs in order to have some
(general) keys (that are set in my general menu) but it doesn't work.
The state oEvent:Message == WM_KEYUP is never reached.
It must be something trivial that has to do with dialog ?? (or not)
Could you tell what basic thing is wrong ?
John
METHOD Dispatch(oEvent) CLASS frmDlnLijst
DO CASE
CASE oEvent:Message == WM_KEYUP .and. oEvent:wParam == VK_F2
*
* F2 voor einde
DO CASE
CASE IsMethod( oEvent:oWindow, #EndDialog )
oEvent:oWindow:EndDialog()
RETURN 1L
CASE IsMethod( oEvent:oWindow, #EndWindow )
oEvent:oWindow:EndWindow()
RETURN 1L
ENDCASE
CASE oEvent:Message == WM_KEYUP .and. oEvent:wParam == VK_F .and.
IsKeyCtrlOn()
*
* Ctrl-F voor zoek
IF IsMethod( oEvent:oWindow, #Zoek )
oEvent:oWindow:Zoek()
RETURN 1L
ENDIF
ENDCASE
RETURN SUPER:Dispatch(oEvent)
Geoff Schaller
I think maybe you missed the most important line <bg>
> > F2 is trivial - you can get it in any edit control dispatch with
> > oEvent:Message as WM_KEYDOWN or WM_KEYUP and oEvent:wParam = VK_F2
Note that the messages are detected in the Control dispatch. Not the
window. It is not guaranteed that all controls necessarily pipe all
messages up to the owner window - you may need to provide this mechanism
in your base control classes.
Geoff
John Martens
Indeed I overlooked the refeece to the Control (and not Window).
But how can this Dispatch work for trapping F1 ?
Or is WM_HELP a special thing ?
The problem with the Dispatch of a control is that I should write a
Dispatch for every control on a Dialog window in order to make something
simple as Ctrl-F (for Find) possible for the Window.
The datawindows are no problem because they use the accelerators of my
menu to do this.
So my solution was ..... to assign the ShellMenu accelerator to the
dialog window.
Much more simple then the Dispatch and it also works.
Thanks for the hints.
John
METHOD Dispatch(oEvent) CLASS frmInschrUitloten // This is dialog Window
DO CASE
CASE oEvent:wParam == SC_CONTEXTHELP
SELF:HelpHelp()
CASE oEvent:Message == WM_HELP
// F1: No shift or control allowed
IF _And( GetKeyState( VK_SHIFT ), 0x80) == 0 .AND. _And( GetKeyState(
VK_CONTROL ), 0x80) == 0
SELF:HelpHelp()
RETURN 1L
ENDIF
CASE oEvent:Message == WM_KEYUP .and. oEvent:wParam == VK_F2
*
* F2 voor einde
DO CASE
CASE IsMethod( oEvent:oWindow, #EndDialog )
oEvent:oWindow:EndDialog()
RETURN 1L
CASE IsMethod( oEvent:oWindow, #EndWindow )
oEvent:oWindow:EndWindow()
RETURN 1L
ENDCASE
CASE oEvent:Message == WM_KEYUP .and. oEvent:wParam == VK_F .and.
IsKeyCtrlOn()
*
* Ctrl-F voor zoek
IF IsMethod( oEvent:oWindow, #Zoek )
oEvent:oWindow:Zoek()
RETURN 1L
ENDIF
CASE oEvent:Message == WM_KEYUP
ToonMelding('SU','WM_KEYUP: '+NTrim(oEvent:wParam),SELF)
ENDCASE
RETURN SUPER:Dispatch(oEvent)
Geoff Schaller schreef:
Geoff Schaller
Help is special because it is trapped at a lower level. In fact it's a
system key. So too are things thing F10 etc. So for the F1 that is why I
use the BeforeDispatch() and that way, you cannot go wrong. Also, take a
look in the SDK at the window and control dispatch methods where you
will see how the GUI classes process HELP. Its interesting and may give
you some other ideas for trapping and using the various help keys.
(Email me direct if you want some examples)
Geoff
PS - You should write a dispatch for all your subclassed controls (and
all controls should be subclassed for this very reason). It makes it
easier to add additional functionality like this in the future.
"John Martens" <CA...@TennisHulp.info> wrote in message
news:CA...@TennisHulp.info:
Don Carslaw
Hi John,
Some time ago I posted something about Keyboard hooks, based on work by
Lutz Eckert. I think it was called SetHotKeys - try Google search.
It works great for me, it might be if use to you ... although I haven't
studied your request in depth!
Don
Geoff Schaller
The trouble with keyboard hooks and hotkeys are that they can affect
other applications running on the same PC. This can be a big turn off
for users. So, whilst they work great, you just need to be aware of the
downside.
Geoff
"Don Carslaw" <jcarslaw~REMOVEME~@~REMOVEME~amadeus.net> wrote in
message news:jcarslaw~REMOVEME~@~REMOVEME~amadeus.net:
Paul Piko
> applications running on the same PC. This can be a big turn off for users.
> So, whilst they work great, you just need to be aware of the downside.
Keyboard hooks can be restricted to a specified thread.
--
Paul
----
Paul Piko
Piko Computing Consultants
http://www.piko.com.au
Geoff Schaller
_GetInst(),GetCurrentThreadid())
So if the last parameter is not 0 its restricted to our thread.
Thanks for the reminder. We'd had 0 there.
But Hotkeys seem to be a problem still.
Geoff
"Paul Piko" <pikoccs...@yahoo.com.au> wrote in message
news:pikoccs...@yahoo.com.au:
Paul Piko
> Ah! Ok, SetWindowsHookEx(WH_KEYBOARD,@KeyHook(),
> _GetInst(),GetCurrentThreadid())
>
> So if the last parameter is not 0 its restricted to our thread.
> Thanks for the reminder. We'd had 0 there.
That's right, if you pass zero it works system-wide otherwise it works on
the specified thread.
Don Carslaw
Geoff,
As Paul has said, they work fine if restricted to GetCurrentThreadid().
The reference to 'Hot keys' is a bit confusing. In fact, before using
Lutz's code I tried 'registering' windows hot keys, but hit exactly the
problems you describe, hence the change.
I set my keys up from my base shell class by SetHotKeys(SELF,
SELF:ReadHotKeys()).
SELF:ReadHotKeys() reads "methodname={vkeyasc,keyasc,methodparam1}" from
an .ini file section [hotkeys] and parses that into a global 2-dim array
that looks like {{[methodname],vkeyasc,keyasc,methodparam1}, ...},
although you could of course hard code this.
This array is then used by Lutz's SetKBHook() and __AFKeyBoardHook()
functions.
This functionality is available by default to all my apps from this
section [hotkeys]. All I have to do is enter any app specific 'hot' keys
text into this section, without writing any more code.
Don
Geoff Schaller
"Don Carslaw" <jcarslaw~REMOVEME~@~REMOVEME~amadeus.net> wrote in
message news:jcarslaw~REMOVEME~@~REMOVEME~amadeus.net:
Gary Stark
John Martens wrote:
> Geoff,
>
> Indeed I overlooked the refeece to the Control (and not Window).
> But how can this Dispatch work for trapping F1 ?
> Or is WM_HELP a special thing ?
>
> The problem with the Dispatch of a control is that I should write a
> Dispatch for every control on a Dialog window in order to make something
> simple as Ctrl-F (for Find) possible for the Window.
No, you use a BeforeDispatch handler in your ShellWindow. At this point
you can direct the captured keystrokes anywhere that you wish.
--
g.
Gary Stark
gst...@RedbacksWeb.com
http://www.RedbacksWeb.com