1. The Print Screen key does not generate a WM_KEYDOWN message. Instead it generates a WM_SYSKEYDOWN message with (typically):
wParam = 12h
lParam = 20380001h
2. The alt key likewise generates a WM_SYSKEYDOWN message with the same parameter values. The only difference is that the alt key first generates a WM_SYSKEYDOWN message with wParam = 12h and lParam = 21380001h (key is extended).
It may be possible to use this difference to sort out the WM_SYSKEYDOWN messages that come from the Print Screen key and not from the alt key (or the control key or other as yet unknown keys).
3. Registering the Print Screen key as a hotkey works well, except that it appears to preempt the key and make it useless for other instances of the same application and no doubt other applications.
Question 1: Is there a way to register a hotkey locally, as it were, so that other applications or instances of the same application are free to register it for their own use?
Question 2: (If not) Is there may be a way to allow instance 2 of an application to receive WM_HOTKEY messages for a hotkey registered by instance 1?
Question 3: Is there something I am missing or may it be necessary to do a keyboard hook?
Thanks, Robert
Quote from: raleep on December 27, 2012, 06:26:05 PMQuestion 2: (If not) Is there may be a way to allow instance 2 of an application to receive WM_HOTKEY messages for a hotkey registered by instance 1?
yes, if the instances can see each other, notification using messages is possible.
Quote from: qWord on December 27, 2012, 06:49:51 PM
Quote from: raleep on December 27, 2012, 06:26:05 PMQuestion 2: (If not) Is there may be a way to allow instance 2 of an application to receive WM_HOTKEY messages for a hotkey registered by instance 1?
yes, if the instances can see each other, notification using messages is possible.
Ah! Thank you. I have not tried to implement inter-instance communication, but it looks doable. Perhaps instance 1 could rebroadcast (something) on receipt of a hotkey, perhaps something usable more generally.
RegisterWindowMessage is a good way to exchange messages inside the same window class. Otherwise, for passing more than just two dwords, use WM_COPYDATA.
Quote from: raleep on December 27, 2012, 06:59:52 PMI have not tried to implement inter-instance communication,
that is commonly called interprocess communication (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx).
Alos a very simple approach (if no window available) is to create a invisible/message-only window with a specific class name for communication. Just enumerate all windows, compare their class name and if match, send the notification. (e.g. WM_USER+x)
from what i can see, wParam for the PrintScreen key should be 2Ch (VK_SNAPSHOT), not 12h (VK_MENU)
perhaps the function keys being locked or the scroll lock/num lock state is altering the value
also, notice that, after you have processed the keypress....
if you exit WndProc via RET with EAX = 0, the system does not see the sys key press
if you want the OS to process the key press, exit via DefWindowProc, instead
for most WM_SYSKEYDOWN and WM_SYSKEYUP messages, i exit via DefWindowProc
i believe this is somewhat standard behaviour
Quote from: qWord on December 27, 2012, 07:47:51 PM
Alos a very simple approach (if no window available) is to create a invisible/message-only window with a specific class name for communication. Just enumerate all windows, compare their class name and if match, send the notification. (e.g. WM_USER+x)
For messages between processes that may contain multiple window classes you should use WM_APP not WM_USER. WM_USER messages can conflict with common controls, they should only really be used for communicating with windows within the same process. The WM_APP group is guaranteed not to be used for any existing window messages and is safe for communication between processes.
playing with it a little more, i cannot get a WM_SYSKEYDOWN message with print screen - lol
i am using XP SP3
looks like you may need a keyboard hook :t
Quote from: Donkey on December 27, 2012, 09:41:03 PMWM_USER messages can conflict with common controls, they should only really be used for communicating with windows within the same process.
If he creates his own class, there should be no problem with WM_USER.
i don't know what all this IPC stuff is about - lol
create a keyboard hook
only the window that has focus will receive keyboard input
MSDN: (http://msdn.microsoft.com/en-us/library/windows/desktop/ms644947%28v=vs.85%29.aspx)
Only use RegisterWindowMessage when more than one application must process the same message. For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF. (Messages in this range are private to a window class, not to an application. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use values in this range.)
Which implies that RegisterWindowMessage avoids the problems with common controls.
Quote from: Donkey on December 27, 2012, 09:41:03 PMThe WM_APP group is guaranteed not to be used for any existing window messages and is safe for communication between processes.
This also avoids the problems with common controls, of course. But you would have to know the handle of the other instance to send the message (->EnumWindows, FindWindow, ...). I have not tested it, but probably a WM_MyRegisteredMsg would work with HWND_BROADCAST - and not reach windows outside a given class. To be verified...
Quote from: jj2007 on December 27, 2012, 10:14:00 PM
MSDN: (http://msdn.microsoft.com/en-us/library/windows/desktop/ms644947%28v=vs.85%29.aspx)
Only use RegisterWindowMessage when more than one application must process the same message. For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF. (Messages in this range are private to a window class, not to an application. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use values in this range.)
Which implies that RegisterWindowMessage avoids the problems with common controls.
Can't argue with that, makes pretty good sense and avoids the traps of WM_USER across processes.
Donkey, JJ,
If I send a message to window of my own class, there is definitely no problem with WM_USER because only this window will get the message. I was never talking about broadcast messages.
The print screen key doesn't work on my laptop like on many other computers.
To get a screen shot you have the hit a fn button and the combination insert/prt scr button.
There some other key combinations oddities on hp laptops.
Can you use the keybd_event API to simulate the PRINT SCREEN key?
On my Windows 2000 system the Print Screen key generates only a WM_KEYUP message with wParam = VK_SNAPSHOT. Is this not enough to trap the key?
Hi MichaelW,
You are right. Detecting the WM_KEYUP message with wParam = VK_SNAPSHOT is doing the job. I attached an example. Hitting PRINT SCREEN while the window is active will display a message box. ( see the attached example )
this seems simple enough :P
warning: you won't here a beep under vista - too bad, so sad
It beeps using Fn + PrtScr.
oops :P
you caught me
i didn't filter out the shift-key cases
easy to do, though
The PrtScr key doesn't work on IBM Thinkpads like it does on most other computers.
It takes hitting a key labelled fn + PrtScr/insert to save an image.
Quote from: Magnum on December 28, 2012, 08:33:31 AM
The PrtScr key doesn't work on IBM Thinkpads like it does on most other computers.
It takes hitting a key labelled fn + PrtScr/insert to save an image.
This is normal for laptop keyboards. To reduce their size, some (hopefully lesser used) keys are escaped by the Fn key. So, Insert/PrtScr is the Insert key by default, but can be transformed into the PrtScr key via Fn.
I miss the extra number keys.
I like to make some of the extended ascii characters on occasion.
you might write a little program to show the ibm graphics char set (OEM_CHARSET)
then - pick one and it puts it into the clipboard :P
Quote from: Magnum on December 30, 2012, 04:15:00 AM
I miss the extra number keys.
I like to make some of the extended ascii characters on occasion.
NumLock activates the number keypad - notice the letter keys on the right also have numbers?
Then you can just hold alt and enter a character number, as usual.
Of course, a tray icon with a popup palette to select characters would be nicer..
you could probably get the handle of the window that has keyboard focus before you show the window
then - send WM_CHAR directly - no clipboard
i think we are well on our way to developing "the next big app" :biggrin:
I thin a big app would show the supervisor password for the BIOS chip made by a company that thought frustrating users is funny. :biggrin:
get a rope !
actually, it is hackable
you should be able to boot up in DOS and dump the flash contents
one of the things about assembly language - if you know your way around, there are no secrets