Hotkeynet comming back?

[Freddie]

3. When I want to shut down Hotkeynet I get the Hide/Shutdown dialog. Could you place a "Do not show this again" checkbox there or offer a Shutdown button next to the Hide button on the main window?

I did this today. It's in build 44. Thanks for the suggestion.

[HomersDonut]

I figured out a workaround to be able to stop transmitting to an instance -Have the instance stop listening. I bound a hotkey to rename an instance from 'Box1' to 'Box1Off'. That way you prevent that instance from recieving any keys as well as having an on/off indicator via the window's titlebar.

Just thought I'd share this

[Freddie]

That's a great idea. Unfortunately, if I remember correctly, whenever HotkeyNet fails to find a window, it cancels the rest of the macro on the receiving PC, so this could affect not only the renamed window but also other windows defined in the same hotkey.

I'll check the code and if I'm remembering correctly, I'll change the program so this idea works all the time.

[Katharsis]

Great job, Freddie! I've got Hotkeynet running fine on Vista Ultimate and XP. Thanks for the quick respone on requested changes.

I'm planning to design a completely new interface for the program after the feature set is complete,

Will there be skins? *snicker*

[kandore]

First of all, I really love the program. I've read through your website tutorial and it all seems to make sense, but on my first test macro I'm running into a problem. On my client computer I have EQ2 running titled just as EQ2. I have all of my spells that I need on my hotbar assigned to a number or combination of CTRL/ALT and a number. I plan on using my server computer to run one toon using regular macros from the in game hotbar, but to be able to press F1 through F12 to access spells and macros on the second computer. My first hotkey from my server computer looks like this (with my actual IP address instead of the words)...

<hotkey F1>
<sendpc ipaddress>
<sendwin EQ2>
<keydown>1<keyup>

I keep getting an error in HotKeynet on my client computer that says
"Unknown command or keyname:."
then after I hit OK it says the same thing again, but continues to cast the spell in EQ2. I wouldn't mind the error except I have to physically click OK twice before the spell gets cast, and by that time I'd probably be dead, lol. Am I making a silly syntax error or something like that? Thanks for your help, can't wait to use the program more!

[kandore]

Ha, nevermind. It didn't like my keydown and keyup commands. I just told it <1> instead and it worked just fine.

[Freddie]

Thanks for the kind words. I'm glad you got it figured out. I'm also glad you told me about the problem because it shows a weak area in the program that needs to be improved. What should have happened, when you put <keydown> in your file, is that the program should have told you:

"keydown" requires the name of a key inside the brackets like this: <keydown F3>

If the program had told you that, the confusion could have been avoided. So I need to add stuff to the program that will check your hotkey files and tell you how to fix the mistakes. And in fact I worked on that today.

By the way, these two commands together:

<keydown 1><keyup 1>

mean "press the 1 key down, then release it." Which is the same thing as simply typing 1. Which is what you did when you simply wrote <1>. In fact, since 1 is an ascii character (a printable character) you could have simply written 1 without brackets. But <keydown> by itself doesn't mean anything to the program.

[Freddie]

Great job, Freddie! I've got Hotkeynet running fine on Vista Ultimate and XP.

Thanks a lot. Very glad to hear it.

Will there be skins? *snicker*

Well... let's just say it's not close to the top of the to-do list.

[Freddie]

I've been busy the last few days adding a big new ability to the program. (This feature isn't available yet in the current build... I need to test it a little bit more.) I've also expanded the documentation. There's now a reference section here:

HotkeyNet Reference

I've also spent time writing a new parsing system that will check hotkey files when you load them. It will point out mistakes to the user and give hints for correcting them. It may be a while before this new error detection is visible in a public build, because I have to rewrite all the existing commands so they make use of it.

[Freddie]

I was thinking about this some more last night. Perhaps change it so that instead of shutting down the keyboard hook, but validates the hotkey against an active/inactive list before firing off the macro.

Sorry it has taken me so long to reply to this post. Thanks for the suggestion. As you know the feature has been implemented so this topic is moot, so I'll just say that in a general way, your suggestion describes what had to be done, but because of the way the program was written, implementing this required changing some things in a way that exposed one encapsulated part of the program to another part. Also an even bigger problem was that the way the program had been written, the commands weren't interpreted until execution time on the receiving pc. But in order to implement this feature, the commands needed to be parsed and understood on the sending pc when the macro file was loaded, prior to execution of the macros. So I had to either write code that duplicated the interpreter's function so the file-reading code could do that, or else I had to modify the interpreter so part of its capability was available at file-reading time. Because of the possibility of introducing bugs due to loss of encapsulation,and because of implementation details, I was reluctant to do these things. But anyway it's done now and seems to have turned out okay.

As for incorporating that into the script, there could be a couple of ways.

<Hotkey X Switchkey> could define a single toggled hotkey, while
<Hotkeygroup Name SwitchKey> ... </Name> could encompass a group of keys with a common toggle.
To toggle on/off actual windows or instances, the Switchkey could be set in the <rename> or <rename_from_path> commands.

Toggle a single hotkey -- this makes me worry about user confusion and support problems. Let's look at things from the viewpoint of the average new user writing new hotkey definitions, trying to get them to work with their game, having difficulties -- and now on top of wondering if they've written the definition correctly, and wondering if they've understood the documentation, and wondering if hotkeynet is bugged, and wondering if this particular feature works with their particular game -- now there's the added complication that they might have turned the hotkey off without realizing it. I dont know if you've ever supported published software (been in the position of getting questions and complaints from customers) but from my position, anything that makes things more complicated and confusing for users can be a headache.

I suppose maybe I could handle that problem with a check box on HotkeyNet that forces everything on, no matter what.

Groups of keys -- At some point it will be a good idea to handle groups of keys. Not only for toggles but for such things as having them on when a particular window is in the foreground. So I think groups have to be dealt with in the same context as conditional execution depending on the foreground window. I think Autohotkey handles this with an "if window is in foreground" construct. HKN eventually needs that sort of thing, and however groups are implemented, their on/off state should be linkable to it. Also I'm planning to add clickable panels of buttons on the screen that will be changeable as different windows come to the foreground. That involves groups of keys too. WhatI'm trying to say is that all these things are tied together, and I can't implement one piece of them until the whole thing is planned.

the Switchkey could be set in the <rename> or <rename_from_path> commands -- I think you're right that eventually the program should have a feature like that, but I'm not sure it would be a good idea to implement it as an argument in those existing functions. The problem is that a user who is looking for a way to turn off keys for a window is going to look through the documentation for a function with a name like "turn off hotkeys for a window." Their eyes will bounce right over "rename" because renaming doesn't seem to have anything to do with turning off hotkeys.

Also, there's a general question about the design of software interfaces about whether functions in an API should do more than one thing. I'm pretty firmly in the camp that says no. My opinion is, a function should perform one action that is clearly indicated by its name. Why? Because for most people, this makes the API much easier to understand and use.

Finally, would there be much demand for <HOTKEYDOWN>and <HOTKEYUP>definitions? My reason is that while WoW's /follow command is cancelled fairly easily, it isn't the case in EQ2 where you can still use left & right movement to circle around your /follow target. Having to repeatedly press an arrow key to have the scout inch around doesn't feel or look very cool

I'm not sure I understand this idea. Do you mean a command that would have the effect of holding the movement key down, and another command that would stop that? If so yes, that needs to be done. It's on the list.

Natively, the <sendwinM> does not work with EQ2 but does under Innerspace (I know, I caved ;( )

Did you try <sendwinM> with <background_setfocus>?

Can you give me a link for Innerspace? I don't know what it is.

That being said, I've seen some very funky key translations happening. For example, a <numpad_minus> key that injects an <equals> to both instances comes though as a <0> on the background instance. Really not sure what is happening there ?

I need to completely rewrite all the keystroke stuff -- it was written very hastily -- but the intention with HKN is that it always merely sends Windows's "official" virtual key codes. And whatever translations are done, are done by Windows, taking into account your keyboard device driver and locale settings and whatever else Windows takes into account. So any mistranslation is either a bug on my part or just Windows being Windows.

Maybe when I rewrite it, I'll include more diagnostic stuff so you can get a better idea what's happening, if possible

Cheers,

Freddie