Receive events on inactive Windows?

[Jedive]

Is it possible for an application to continue receiving events when its window is not the active one?

I am making an application which has a window of size 1x1 outside of the screen range (positioned at -1, -1). When the user presses an specific key (for example, F1), the window will be resized to an appropiate size, and put on the center of the desktop. The problem is that the application only receives the input events (a #WM_KEYDOWN message) when the application is the currently running one, not when it is working on the background.

Is it possible to change this behaviour so the application still receives events when in the background?

[Jellybean]

No, you have to use a keyboard hook or something.

[Edwin Knoppert]

Using a global keyboard hook you can do anything you like.
However, the hook must reside in a dll.
Each app *will* load the dll.. when active + any key is pressed.
You'll need to manage a communication between the dll and your exe since the app actually loading the dll will not be in yopur exe's process.

I know since i did a similar thing (nocaps32.zip in my dl folder)

There is also the HOTKEY approach which is bad.

[Edwin Knoppert]

O, i forgot the timer> poll-for-key-pressed-simple-option?

[Edwin Knoppert]

Putting a window on location -1, -1 might also be a bad idea
Having heard of multiple monitors?

[Jedive]

Thanks everyone for your comments. It id working correctly now

I done it by using the GlobalHotKeys PureLibrary, but I dodn't need to put anything in a dll, Edwin. Everything is on a single executable.

About putting the window on -1, -1, yeah, I did that because I was not sure if it was possible at all to capture events on hidden windows, so instead of hiding it, I moved to that location. Now I have seen that GlobalHotKeys works perfectly even when the window is hidden, so that's what I am doing now

Thanks everyone.

[PB]

> There is also the HOTKEY approach which is bad

Why? A lot simpler than using a DLL and it doesn't require constant polling.

[DoubleDutch]

Use this OS call to register a hotkey...

Code: Select all

RegisterHotKey_(WindowID(),1,modifier,key)

Use this to unregister it...

Code: Select all

UnregisterHotKey_(WindowID(),1)

When registered check for the

Code: Select all

#WM_HOTKEY

message in your window callback.

This is all the library your using probabily does, but may take up less memory.

-Anthony

[Edwin Knoppert]

> There is also the HOTKEY approach which is bad

Why? A lot simpler than using a DLL and it doesn't require constant polling.

It's obvious, you might mess with ordinary application behaviour.
Capturing a key but continue in a global hook is different.
I'm not sure but i thought the hotkey will cancel an app's key.

Also, you might overide a previously hotkey set.. exactly why i think HK's are a bad approach.

[Edwin Knoppert]

>... a DLL and it doesn't require constant polling.

To be clear, i did not suggest a timer in a dll.

[DoubleDutch]

Also, you might overide a previously hotkey set.. exactly why i think HK's are a bad approach

If you try to set a hotkey that already is in use, the result will tell you.

-Anthony

[PB]

> I'm not sure but i thought the hotkey will cancel an app's key

True, but only if you set a common key... for example setting "A" as a
hotkey will stop "A" being used in all other apps, but that would be a silly
thing to do.

> you might overide a previously hotkey set

Impossible, because the system would reject it and fail the registration.

> To be clear, i did not suggest a timer in a dll

I didn't mean the DLL was polling, I meant it as a separate solution, as in:

Code: Select all

; This halts your app until F1 is pressed when any window has the focus.
Repeat : Sleep_(1) : Until GetAsyncKeyState_(#VK_F1)<>0

[Edwin Knoppert]

Also, you might overide a previously hotkey set.. exactly why i think HK's are a bad approach

If you try to set a hotkey that already is in use, the result will tell you.

-Anthony

Can be, therefore it remains a bad scenario..

[Edwin Knoppert]

>Repeat : Sleep_(1) : Until GetAsyncKeyState_(#VK_F1)<>0

Also a bad loop, it will most likely eat processortime.
While a timer loop only does on idle state.

I know this is prob. for hobby anyway, for real apps it remains a bad approach.

You should go back what it should do, you want to know if a certain key is pressed...
All the HK and even the timer is a so-so solution.
Maybe even the purpose might be so so.
(In fact, the purpose is unclear, it was only a request how to deal with this)

[DoubleDutch]

Can be, therefore it remains a bad scenario..

I don't understand what you mean, the result will mean that your request has failed - so pick another key.

What does "Can be, therefore it remains a bad scenario" mean???

-Anthony