Hotkeynet and Kavoom and getting started

[Freddie]

It's good to coordinate like this. When my hook receives key events, it lumps together real keypresses and injected ones from other programs. It treats them the same way because users frequently want to trigger hotkeys with another program's output.

But it distinguishes its own injections and ignores them in order to avoid an endless loop where a hotkey triggers itself. (If a user really wants to trigger a hotkey from another hotkey, there's a safe way to do that.)

It just occurred to me. Maybe all of us "multiboxing developers" should agree on a standard where one of our programs can ask another one to ignore our keystrokes, or something like that. Maybe a message that we send to the other guy's program where one of the param's is our extra info number. Would that be useful? I dunno.

[skarlot]

for example, my KM will use one number for its special server position checks, and another for its standard input.

you want something like, when an app starts it says, "is there any multi boxing apps in the building? identify yourself! " "what are you doing here? "

sounds like work lol... worth a thought

[Freddie]

I don't know if it's worth it. I only suggested it because I thought maybe i was getting in your way by doing something with your keystrokes. So the idea is to give you a way to ask my program to ignore your keystrokes. But if that's not the case, forget the whole thing.

It could just be a message that you'd send saying, "Please ignore injected keystrokes with my extra info number on them."

On the requesting side it could be real simple, even just one line of code like this:

BroadcastSystemMessage ( BSF_POSTMESSAGE,
                         WM_SOME_NUMBER_WE_AGREE_ON, 
                         BSM_APPLICATIONS, 
                         MY_EXTRA_INFO_NUMBER,
                         ANOTHER_NUMBER_WE_AGREE_ON_TO_MAKE_SURE_THE_FIRST_NUMBER_IS_NOT_A_COINCIDENCE );

It would be a little more work for the receiver -- we'd have watch for that message and keep a list of extra info numbers that we're supposed to ignore.

[skarlot]

well you said you took injected/uninjected events the same right. and you provide the option to swallow the event, in the script. if thats the case i don't tihnk providing your program with an EEN to ignore is helpful since it sounds like it could override behaviour you have with a standard keyboard? excuse me if i'm wrong, ive had a few beers. My KM could potentially benefit from notification that HKN was going to reinstall a server side keyboard hook, so it can stay consistent, as a KM is arguably lower level, maybe that is something. I just look for process launch and reinstall hooks.

[Freddie]

What's the easiest way I could notify you?

By the way, all copies of HotkeyNet install a keyboard hook every time they launch, so if you know the program launched, you know it installed a hook. And that's the only time. The reason the clients do that is because they have the same abilities as the server. With HotkeyNet the server/client distinction applies only to the communications protocol, not to sending or receiving commands.

It's harder to know if I installed a mouse hook because I only bother with that if the user defined hotkeys with mouse button triggers. And that can get reinstalled without relaunching the program. Do you need to worry about that? i saw you wrote that you're using RawInput in your new program.

I wonder if there's some way to find out a hook's location in the chain.

[skarlot]

I don't think so - not for now!

Maybe you can watch for every process launch, then patch user32.dll lol and detour setwindowshookex ... somehow. Otherwise I don't know of a way.

You still need a mouse hook when switched to a client, since RawInput is not gonna let you choke the mouse input. Plus, it is a bit slower so I use it only when I found neccessary :-)