Hotkeynet and Kavoom and getting started

Ok - so that I can keep my hair I have to ask for help.

I'm actually trying to set this up on five boxes - but I broke it down to two until I can get two boxes working.

Two computers and a simple setup.

Code:

---

<Label w1 192.168.1.X SendWin "WoW1">
<Label w2 192.168.1.Z SendWin "WoW2">


<Hotkey ScrollLockOn A-Z, 0-9, F1-F12, Minus, Plus, Space, ESC, OEM2, Enter, Backspace>
        <SendLabel w1, w2> <Key %Trigger%>

---

Machine with w1 is the HKN server
When I use the keyboard to either machine and type locally on a local window - then everything works as expected - the keystroke is sent to the local and remote windows as expected.

Now if, from either machine, I slide over to the other machine (Kavoom KM installed all the time) then I get double input on the machine the kavoom focus has moved to and nothing on the machine the real keyboard is local to. (When using all 5 machines - the three other clients get the keystroke)

I've tried loading KM before HKN and vice versa - same situation.
Clearly there is some setting or something I am missing. I'm tired so this post might not even make sense.

Thanks to anyone for any input here.

When you Kavoom over to a remote PC there has to be a Hotkeynet file loaded on that machine as well to send commands. I couldn't determine from your post if you have done that.

I have this file loaded on both machines. The latest HKN version automatically translates the local ip in the script as LOCAL for Sendwin etc. so there is less editing files between machines.

When I have all 5 machines up and I mouse to a different machine - that machine gets 2 copies of the key, the other 'slaves' get a copy but the main gets none.

Main - any computer I am using an actual keyboard from ( I have two)
Slave - anything I mouse to with Kavoom.

You may be tired but you described that extremely clearly. Thanks. :)

Sounds to me like the first problem (double keystrokes on the remote) is caused by both programs doing what they are supposed to do. When you slide the mouse to a remote and press a hotkey on the local, both Kavoom and HotkeyNet are supposed to send a keystroke to the remote. They are both doing their jobs and you get doubles.

As for the second problem, I'm guessing that Kavoom is accidentally blocking HotkeyNet's injected keystrokes on the local while the mouse is slid to the remote. That's a perfectly natural thing for Kavoom to do because when you slide the mouse to the remote, Kavoom is supposed to block your physical keypresses on the local keyboard from reaching any local apps. When you use SendWin with HotkeyNet, its injected keystrokes are almost indistinguishable from physical ones, so it wouldn't surprise me if the method Kavoom uses to block input is affecting not only physical keystrokes but HotkeyNet's injected ones as well.

If I've diagnosed the second problem correctly, you can probably fix it by using SendWinM instead of Sendwin.

However I can't think of any solution for the first problem except, "don't press a hotkey while the mouse is slid over to a remote."

It's too bad that Kavoom doesn't have an option to disable keyboard switching while enabling mouse switching -- that would probably fix the doubles problem -- but I just checked the Kavoom documentation and it's not mentioned.

P.S. There's a guy named dcreager on the HoktkeyNet forum that uses Kavoom and HotkeyNet together. Maybe he can tell you something if you send him a PM over there.

I'll send him a PM right away - thanks.

I frequently have to slide to another computer and use that character as leader (I play on a pvp server and they think they have me when they SAP my leader) so I need to find a way around "don't slide to another computer" :)

If I was able to disable keyboard switching while allowing mouse switching - how would I test for which window the input was coming from? (for using the FLT setup)

I don't think I would be able to use "If ActiveWinIs WoW1" to test which keys to send to remotes.

What other KM software works with 5 machines and doesn't do the spin of death when mouse-looking?

I use multiplicity and hotkeynet without any real trouble.

It might be worth trying a different file on each PC using <local> and IP rather than both as IP's.

I did have an issue with sendwin and vista which may have been multiplicity I guess but sendwinm resolved this like Freddie said.

well I briefly tested my new KM with HKN without a great deal of joy on the weekend...

I took the path of stopping other hook apps locally seeing events ( or rather providing that option ) because this is what I think would work right with keyclone, which is proven to double key, and the fact there would be no way to tell a broadcasting app which pc the "real" input is at, without an API...

I had 2 scripts, one on my main PC one on PC 2. At times I thought HKN wasn't allowing any injected input on the client, rather than just events with a particular extra info number.... but im not sure

anyway, I will add whatever options are appropriate,..

Edit: If you think HotkeyNet should be changed to make it friendlier to other programs, please tell me how. I'm open to suggestions. As for the current build:

The only time HotkeyNet interferes with another program's injected keystrokes is when the user has defined those keystrokes as the trigger of a hotkey and the hotkey definition calls for the trigger to be swallowed.

In other words, HotkeyNet only does it when the user explicitly tells it to do it.

On the output side, HotkeyNet signs its own injections partly as a convenience to me but also as a convenience to other programmers.

Here are some details:

-- HotkeyNet gets its keyboard input from a low level keyboard hook.

-- The hook proc decides whether a keyboard event is the trigger of a defined HotkeyNet hotkey and if so, depending on whether the definition calls for the trigger to be swallowed, the hook proc swallows the event by returning a non-zero value to the operating system.

-- At all other times the hook proc calls the next hook in the chain without altering anything.

-- HotkeyNet accepts both physical keystrokes and those injected by other programs as triggers.

-- HotkeyNet signs its own SendWin injections with a constant -- I forget the number but you can see it in the debugger or I'll look it up if you want -- so you can easily handle HotkeyNet's injections as a special case if you want to do that.

That clarifies it. I took the extra info number and have added:
an option to let key, click, wheel events inject on the server while on a client (but not retransmit). (Interbox always lets movement through).
an option to allow other applications to see key events while on a client. (ie, call rest of hook, but return 1). I didn't apply this to clicks, since it doesn't seem to make sense if there was no useful cursor position to go with.

In the past I found that standard mouse buttons may flag as injected, thus I apply this concept to keys as well and only block events with my extra info number on it (with Octopus).

Interbox does not use a regular extra info number in it's current version, i should do.

I think all in one is easier, and it's simpler to produce a low latency program that way. Clearly ProgramW is for that so I've added a few simple options (0.98+), that may suit different setups with HKN... based on my limited knowledge.

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.

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

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:

Code:

---

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.

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.

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.

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 :-)