PureBasic Forums - English

>> Repeat : Sleep_(1) : Until GetAsyncKeyState_(#VK_F1)<>0
>
> a bad loop, it will most likely eat processortime

Well, 0% CPU isn't much processor time for such a tight loop.

DoubleDutch wrote:

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

I said using HK's is a bad approach since it can interfere or as you state fail to initialize die existing HK.
That sounds as a poor scenario if this part is failing for some reason.
are you gonna present the end-user with a dumb message like "sorry hotkey does not work, bye"

Iow, your program should always work (unless it's for hobby)

Clear?

PB wrote:>> Repeat : Sleep_(1) : Until GetAsyncKeyState_(#VK_F1)<>0
>
> a bad loop, it will most likely eat processortime

Well, 0% CPU isn't much processor time for such a tight loop.

Hmm, i don't know how this behavious exactly.
If GetAsyncKeyState_() is holding the app.. it would do indeed.
But, if not you are continously in a loop instead, and should eat cpu time.

You could say "hotkey already allocated", then go to you dialog to set up a new hot key?

DoubleDutch wrote:You could say "hotkey already allocated", then go to you dialog to set up a new hot key?

That really depends on the app, isn't?

Try the GetAsyncKeyState loop and check it with any CPU monitor... they
all report 0% CPU usage, due to Sleep in the middle. If you remove the
Sleep, the CPU jumps up to 99% usage immediately. Remember, it's a
tiny loop that doesn't do much at all -- why would you expect the CPU to
work overtime with it? The loop does hardly anything at all.

A loop is a loop.
After your post i expected an odd behaviour like Windows waits in the api for a key.
(I had some trouble with the KB api's in the past so therefore me thinking this way )

You are lucky the sleep is preventing blocking and as you say seems to keep the app idle... somehow.
For myself i would not rely on that behaviour under different os's.
Sleep is not the same as calling a specially crreated api as used in a windows msgpump: GetMessage()

How windows is keeping the loop/app idle in this call is their way and works as expected.

Maybe less understood, the msgpump loop is always stuck in the GetMessage() API *except* when a message needs to be executed.
Then it will be released and your loop will do a new cycle.

I know, this is not related directly but i wanted to explain sleep is different.

Hmm, i just read about the sleep API and it seems to do what you want:

>A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run.

etc..

Well, you may be in luck

I have to intercept any mouse movement, keyboard press, to launch an event after some time of inactivity, just like the task that launches a screensaver...

Is it possible to use GetAsyncKeyState for any key instead to check ANY possible key?
What about mouse movement?

Thanks a lot.

KameHameHaaa wrote:I have to intercept any mouse movement, keyboard press, to launch an event after some time of inactivity, just like the task that launches a screensaver...

me too!

KameHameHaaa wrote: Is it possible to use GetAsyncKeyState for any key instead to check ANY possible key?
What about mouse movement?

I found that you can capture mouse movement globally with DesktopMouseX() and DesktopMouseY() - even when the application looses focus, this seems to continue to work. (at least on Windows, haven't had the opportunity to test with Linux)

I'm searching high and low for a global keyboard hook myself - I wish it could be built into PB, as the time-tracker application I need to write has to work both on Linux and Windows, so a Windows-specific implementation does me little good... (of course, a library would do nicely too, but I don't know anyone with the Linux skills)