[HotKeyNet] Sending keystrokes from slave to master?

[Nomahd]

I've been using HotKeyNet for a little while now and it works very well for me. But I decided to try and get a FTL setup going between my 2 computers. I also use Input Director to allow me to control the second computer screen as if I had dual monitors.

The problem that I am having is I cannot get anything to transmit to the master if the slave system has focus. Transmitting to the slave when the master has focus is no problem. Am I missing something or is this just not possible? I've tried various sample FTL scripts and nothing has worked yet. If I could just get it to work once then I would be able to continue with my setup.

Here is a test script I tried and it sends from the master to the slave but not from the slave to the master.

<Label w1 192.168.0.110 SendWinM WoW1>
<Label w2 192.168.0.109 SendWinM WoW2>

<Hotkey ScrollLockOn Alt Ctrl L>
<SendPC 192.168.0.110>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW1>
<wait 10000>
<SendWinM WoW1>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>
<SendPC 192.168.0.109>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW2>
<wait 10000>
<SendWinM WoW2>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>

<Hotkey Numpad1>
<If ActiveWinIs WoW1>
<SendLabel w2>
<Key Numpad1>
<Else If ActiveWinIs WoW2>
<SendLabel w1>
<Key Numpad1>

[Khatovar]

What does HKN say when you try to send the key from the slave?

[Freddie]

The If-statements in your <Hotkey NumPad1> are asking which WoW has the focus on the local PC.

But one of the WoWs is running on the remote PC. It never has the focus on the local PC. Therefore, one of the If-statements in your hotkey can never be true and it can never execute.

If you want HotkeyNet to do something conditionally based on conditions on the remote PC, you need to load a script on the remote PC. Put a hotkey in that script with the appropriate If-statement. Then trigger that hotkey from the local PC with a second hotkey definition that includes <DoHotkey ...>.

P.S. Each of your machines has its own active window (a window that has the focus). Input Director (like all KM programs) disguises this fact from you by making it appear that there is only one active window for both machines. But really there are two active windows at all times, one on each machine. You may need to take this into account.

[Nomahd]

Okay, that makes sense. I was thinking that might have been the problem after I posted this but I wasn't sure what to do about it. I wasn't aware I could load a script into the slave client. I'll mess around with it some more tomorrow and post back the results. Thanks for the input.

[Freddie]

You can load scripts into any copy of HotkeyNet and press hotkeys on any keyboard, but you probably don't need to bother.

If you can assume that when the local WoW's not active, the remote one is, you can just replace the second If with Else.

And you don't need to rename the WoWs. Renaming is only necessary to distinguish multiple instances on the same PC.


<Hotkey Numpad1>
<If ActiveWinIs "World of Warcraft">
<SendLabel ....>
<Key Numpad1>
<Else>
<SendLabel ....>
<Key Numpad1>

[Nomahd]

Yeah, I'm aware of that. I did the renaming because I actually run 4 toons on one box and 1 toon on the other box. So I just rename them all WoW1-WoW5 so I know which window is which. I was only doing 1 on each box until I get this issue worked out. So using "Else" will not work for me because I have 3 other toons. ;)

[Freddie]

I was only doing 1 on each box until I get this issue worked out..

You must be a programmer. :)

One of the things I've learned from supporting HotkeyNet for four years is that it doesn't occur to people that the way to write complex scripts is to start with something simple. After the simple thing is working, add to it and make it more complex.

It seems like the most obvious thing in the world, but it just doesn't occur to people. It never ceases to amaze me. They will post 200-line definitions with embedded templates and includes and say, "I can't figure out what's wrong. Help!"

Well of course they can't figure out. The definition is too complicated. I can't figure it out either. :)

[Nomahd]

You must be a programmer. :)
Guilty. :D
I've dabbled in programming as a hobby since I got my first computer (Commodore 64) like 20 years ago. It seems that no matter how much you know about computers there are always new things to learn, and new problems to face.


One of the things I've learned from supporting HotkeyNet for four years is that it doesn't occur to people that the way to write complex scripts is to start with something simple. After the simple thing is working, add to it and make it more complex.

It seems like the most obvious thing in the world, but it just doesn't occur to people. It never ceases to amaze me. They will post 200-line definitions with embedded templates and includes and say, "I can't figure out what's wrong. Help!"

Well of course they can't figure out. The definition is too complicated. I can't figure it out either. :)
I know exactly what you mean! That's why I used such a simple example. It's much easier to fix the problem at hand if you don't have pages of code to sort through.

Anyway, as for the problem, it's gone now. Since I learned that I could load a script on the slave client all of my problems have disappeared. I can't believe that after looking through pages and pages of Google results for HotKeyNet, FTL, etc. that I never once seen anything stating to put a script on the slave client. It might have been stated and I just missed it...:rolleyes:

Here's the revised example script and the slave client script I used to test (just in case this helps someone else):

Master Client:

<Label w1 Local SendWinM WoW1>
<Label w2 192.168.0.109 SendWinM WoW2>
<Label w3 192.168.0.109 SendWinM WoW3>
<Label w4 192.168.0.109 SendWinM WoW4>
<Label w5 192.168.0.109 SendWinM WoW5>


<Hotkey ScrollLockOn Alt Ctrl L>
<SendPC Local>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW1>
<wait 10000>
<SendWinM WoW1>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>

<SendPC 192.168.0.109>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW2>
<wait 10000>
<SendWinM WoW2>
<SetWinPos 0 0>
<SetWinSize 704 440>
<RemoveWinFrame>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>

<SendPC 192.168.0.109>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW3>
<wait 10000>
<SendWinM WoW3>
<SetWinPos 576 0>
<SetWinSize 704 440>
<RemoveWinFrame>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>

<SendPC 192.168.0.109>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW4>
<wait 10000>
<SendWinM WoW4>
<SetWinPos 0 360>
<SetWinSize 704 440>
<RemoveWinFrame>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>

<SendPC 192.168.0.109>
<Run "D:\Program Files\World of Warcraft\WoW.exe">
<RenameWin World WoW5>
<wait 10000>
<SendWinM WoW5>
<SetWinPos 576 360>
<SetWinSize 704 440>
<RemoveWinFrame>
<text "Account">
<wait 500>
<key Tab>
<wait 500>
<text "Pass">
<wait 100>
<key Enter>


<Hotkey Numpad1>
<SendLabel w2, w3, w4, w5>
<Key Numpad1>Slave Client:

<Label w1 192.168.0.110 SendWinM WoW1>
<Label w2 Local SendWinM WoW2>
<Label w3 Local SendWinM WoW3>
<Label w4 Local SendWinM WoW4>
<Label w5 Local SendWinM WoW5>


<Hotkey Numpad1>
<If ActiveWinIs WoW2>
<SendLabel w1, w3, w4, w5>
<Key Numpad2>
<Else If ActiveWinIs WoW3>
<SendLabel w1, w2, w4, w5>
<Key Numpad3>
<Else If ActiveWinIs WoW4>
<SendLabel w1, w2, w3, w5>
<Key Numpad4>
<Else If ActiveWinIs WoW5>
<SendLabel w1, w2, w3, w4>
<Key Numpad5>As you can see I removed the "IF" in the master script because it only has one window and is therefore always active when the master system has focus. It's still active when the slave has focus too, but then the slave client script supercedes the master client script.

Thanks again for your help! I was getting fed up with searching, which is why I made a thread. It takes a lot of agony to get me to ask for help. I'm a big believer in Google, hehe. Now I can get back to the fun stuff. :cool:

[Freddie]

I can't believe that after looking through pages and pages of Google results for HotKeyNet, FTL, etc. that I never once seen anything stating to put a script on the slave client. It might have been stated and I just missed it...:rolleyes:
I'm sorry. I'm not sure what I can do to make it more clear. HotkeyNet's website says repeatedly that every instance of HotkeyNet has the same abilities. For example, the home page says that you can press a hotkey on any keyboard.

For years, I used to add a sentence like, "With HotkeyNet, every copy can do the same things," to nearly every forum post. I must have done this several hundred times.

The program doesn't distinguish instances of itself. They are all the same. You can load scripts on as many instances as you want.

The problem here is that users assume something that isn't true. I never told them this false thing. They simply assume it on their own. They assume that the server copy of HotkeyNet is a master and the client copies are slaves.

This assumption has always seemed bizarre to me because by definition, a client is a thing that sends commands and a server is a thing that carries out commands. Everybody knows this (or should know this) from web browsers, which are the most common examples of a client-server program. When you tell your browser which web page you want to see, it sends a command to the server. The server, not the client, is the slave.

In fact, "server" is almost a literal synonym for "slave." A slave is a person who is bound to service. "Client" is almost a synonym for "patron", i.e., master. But for some reason people imagine that "server" means "instance that sends commands." I really don't understand it.

But all of this is irrelevant in HotkeyNet's case. With HotkeyNet the client-server distinction only applies to the communications protocol. It has no effect on anything that the user can see. It has no effect on scripts or hotkeys.

I guess part of the problem is that WoW boxers usually think of their groups as consisting of a master and slaves, and they assume HotkeyNet must share this idea. But HotkeyNet has nothing in particular to do with WoW. It's a general purpose hotkey program.

This misunderstanding is one of HotkeyNet's worst problems because it makes people think the program is much less powerful than it really is. If they run four instances of HotkeyNet, they are ignoring three quarters of the program's potential power.

The way I've solved this problem with Mojo is to eliminate clients and servers. Mojo is peer-to-peer and every copy is identical in every way. People won't be able to assume that one instance is different from the others because the instances are indistinguishable.


Here's the revised example script and the slave client script I used to test (just in case this helps someone else):
Nice job! :)

It looks like you're pressing NumPad1 on both keyboards with your finger. If you want to reach back and forth like that, it's perfectly fine.

I myself use three keyboards when I multibox -- I'm really not criticizing this. I like using three keyboards.

But just so people know, if you want, you can set this up so you only have to press one keyboard. You would use <DoHotkey> on your main keyboard to trigger hotkeys on the other computers.


Thanks again for your help! I was getting fed up with searching, which is why I made a thread. It takes a lot of agony to get me to ask for help. I'm a big believer in Google, hehe. Now I can get back to the fun stuff. :cool:
You're welcome! Thanks for posting.

[Nomahd]

I'm sorry. I'm not sure what I can do to make it more clear. HotkeyNet's website says repeatedly that every instance of HotkeyNet has the same abilities. For example, the home page says that you can press a hotkey on any keyboard.

For years, I used to add a sentence like, "With HotkeyNet, every copy can do the same things," to nearly every forum post. I must have done this several hundred times.

That figures... I hate it when that happens. I looked everywhere but right in front of my eyes. But you are right, I assumed HotKeyNet was like a "Master and Slave" type of program.



It looks like you're pressing NumPad1 on both keyboards with your finger. If you want to reach back and forth like that, it's perfectly fine.

I myself use three keyboards when I multibox -- I'm really not criticizing this. I like using three keyboards.

But just so people know, if you want, you can set this up so you only have to press one keyboard. You would use <DoHotkey> on your main keyboard to trigger hotkeys on the other computers.

No, I only use one keyboard. Input Director allows me to use one keyboard/mouse to control multiple computers. So when I move my mouse cursor to another monitor controlled by a different computer (like a multi-monitor pc), the mouse and keyboard output is transferred over to the computer controlling that monitor. So when I pressed Numpad1 on the keyboard it gets sent to whatever PC currently has the focus of the keyboard.

Speaking of Input Director, it IS a master/slave type of program. Which is another reason I was tending to think of HotKeyNet as the same. It also allows macros activated by hotkeys, but not with conditions and no way to toggle hotkeys on or off as far as I could tell. Which makes that function useless to me. But the ability to clone the mouse movement/clicks across multiple computers is handy at times.

I know HotKeyNet allows mouse clicks to be sent to multiple windows, and I use it for that. But it's not the same as a true clone of the mouse cursor. What I mean is live broadcasting of the mouse movements. If I move the mouse cursor in a circular pattern around the screen, the mouse cursor on the other computer does exactly the same in "real time".

I was looking at your Mojo the other day. It looks promising and I can't wait until it's done so I can give it a go! If you can implement the broadcasting abilities of Input Director into Mojo, and Mojo can do anything HotKeyNet can do, I wouldn't need anything else to multibox.

[Freddie]

I was looking at your Mojo the other day. It looks promising and I can't wait until it's done so I can give it a go! If you can implement the broadcasting abilities of Input Director into Mojo, and Mojo can do anything HotKeyNet can do, I wouldn't need anything else to multibox.
Old Mojo (which can still be installed from mojoware.org) is a full blown KM program. But new Mojo doesn't have any KM stuff in it yet.

Mojo's KM stuff is not master and slave. Every mouse on every computer is equal. Every mouse can slide to other computers and control them.

The thing that makes Old Mojo special as a KM program is that it installs and configures itself automatically. It's easier to set up than any other KM program I've seen. What a difference from HotkeyNet! :) On the other hand I never got around to putting lock-to-screen in it.

[Nomahd]

The thing that makes Old Mojo special as a KM program is that it installs and configures itself automatically. It's easier to set up than any other KM program I've seen. What a difference from HotkeyNet! :) On the other hand I never got around to putting lock-to-screen in it.

But does it have as much functionality as HotkeyNet? I stumbled across a post from you about Mojo while looking for an answer to my problem and you said something like HotkeyNet was still your best program to use but that your newest Mojo was going to be better than HotkeyNet when it was finished.

Ease of setup is great. But I would prefer to have a program that can accomplish exactly what I want it to do even if it means I have to spend days/weeks setting it up. That's also why I like Grid for healing in WoW. ;)

I don't find HotkeyNet hard to use at all. But I am also well versed in several different programming/scripting languages as well as experience with reverse engineering (I used to write proggies for games). So I don't know how hard HotkeyNet is to use for the average multiboxer. I'm new to multiboxing and KM software, but old to computers in general.

[Freddie]

But does it have as much functionality as HotkeyNet?
Old Mojo and HotkeyNet are different kinds of programs. They are different categories of software.

Old Mojo is a KM program, not a hotkey program. In other words, Old Mojo is a replacement for Input Director. It's not a replacement for HotkeyNet.


...but that your newest Mojo was going to be better than HotkeyNet when it was finished.
The plan for New Mojo is to combine the features from various multiboxing programs I've written over the years. If I ever finish this project, the result will be much better than HotkeyNet. Mojo will have:

-- automatic installation and network configuration
-- KM features from ProgramW and Old Mojo
-- the new bitcode programming language from HotkeyNet 2
-- the hotkey GUI from Old Mojo


I don't find HotkeyNet hard to use at all.
I wish I could agree with you. :)

I think HotkeyNet is extremely hard to use, and its script language is very poorly designed. I wrote HotkeyNet originally as a quick and dirty prototype and kept building on a weak foundation.

Four times I started to rewrite it from scratch (ProgramW, HotkeyNet 2, Old Mojo, New Mojo) but each time, for various reasons, I stopped and started over.

New Mojo, if it ever gets finished, will have a real programming language (a virtual-machine bitcode language) which I've already written (the new language is in HotkeyNet 2). The new language is elegant and powerful and much easier to use. All its keywords and constructs are fully generalizable. It has real arguments and data types and return values and variables and functions.

It will also have a GUI for such things as toon/team management, screen layout, hotkey definitions, etc.

It will install itself and configure itself automatically to talk to itself on the user's network (it already has this feature). People won't have to be aware of IP addresses or anything concerning communications.

[Nomahd]

Old Mojo and HotkeyNet are different kinds of programs. They are different categories of software.

Old Mojo is a KM program, not a hotkey program. In other words, Old Mojo is a replacement for Input Director. It's not a replacement for HotkeyNet.

Okay, I see. I didn't read up on the old Mojo much. The impression that I got was HotkeyNet is the way to go until the new Mojo is finished so that is where I stopped. I'll just stick with Input Director for now. It does everything I need that I can't get from HotkeyNet. So there's not much point in switching.

I don't even use Jamba... I don't need it. The in-game macro system can accomplish most of what Jamba can. The things which can't be accomplished through a macro can be scripted in a .lua file. As I said, I like total control. ;)



I think HotkeyNet is extremely hard to use, and its script language is very poorly designed. I wrote HotkeyNet originally as a quick and dirty prototype and kept building on a weak foundation.

Don't sell yourself short. It works very well for what it is. I do find it humorous that the creator finds his own creation difficult to use though. :D

Every programming and scripting language started on a basic foundation. Then as needs arised and new ideas developed more functionality was implemented into them. Sometimes they were elevated to an entirely new language. Take a look at DOS. It's very old and basic. But it is still in use today.

Writing a HotkeyNet script is the same concept. You start with something basic (I hope). Then as you get new ideas you add more to it and sometimes remove from it.

Everything was working just fine for me as it was. But I wanted more control and FTL was the route I chose to take. That meant completely re-writing my scripts. Now everything is working well again and I'll continue to add more as needs/wants/ideas arise. I did find a problem in the FTL template provided by Olipcs. (See below)


New Mojo, if it ever gets finished, will have a real programming language (a virtual-machine bitcode language) which I've already written (the new language is in HotkeyNet 2). The new language is elegant and powerful and much easier to use. All its keywords and constructs are fully generalizable. It has real arguments and data types and return values and variables and functions.

It will also have a GUI for such things as toon/team management, screen layout, hotkey definitions, etc.

It will install itself and configure itself automatically to talk to itself on the user's network (it already has this feature). People won't have to be aware of IP addresses or anything concerning communications.

That's what I'm waiting to try out. :)


I don't know if I got a bad example script or if something has changed in HotkeyNet since this was written, but the <PassThrough> in the SendMasterAndSlave template throws the following error:

"PassThrough can only be used as the first keyword in a definition."


//Added FTL Templates
// %1% : Master Key
// %2% : Slave Key
// %3% : Modifier
// %4% : SlavesToSend
<Template SendMasterAndSlave>

<PassThrough> <------- This causes the error

<Sendlabel %4%>
<Key %3% %2%>
<EndTemplate>

// %1% : master key
// %2% : slave key
// %3% : modifier
// %4% : Active window
// %5% : Slave Windows
<Template SendLeaderless>
<If ActiveWinIs %4%>
<ApplyTemplate SendMasterAndSlave "%1%" "%2%" "%3%" "%5%">
<EndTemplate>

// %1% : master-key
// %2% : slave-key
<Template FTL>
<Hotkey %1%>

<PassThrough> <------- So I moved it here and everything worked perfect.

<ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl rshift" WoW1 "w2,w3,w4,w5">
<ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl ralt" WoW2 "w1,w3,w4,w5">
<ApplyTemplate SendLeaderless "%Trigger%" "%2%" "ralt rshift" WoW3 "w1,w2,w4,w5">
<ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl ralt rshift" WoW4 "w1,w2,w3,w5">
<ApplyTemplate SendLeaderless "%Trigger%" "%2%" "rctrl" WoW5 "w1,w2,w3,w4">
<EndTemplate>It's a minor issue, but I thought it was worth mentioning. I've completely revamped these templates now anyway. I test for conditions based on what windows exist since I use the same script to launch multiple toon configurations depending on what I plan to do in the game (Each toon has a dedicated window name).

[Freddie]

Don't sell yourself short. It works very well for what it is.
Thanks. I appreciate that. It's not the worst program I ever wrote, but it's much less good than its replacement will be if I ever finish it.


Every programming and scripting language started on a basic foundation... Sometimes they were elevated to an entirely new language. .
That's what I decided to do with HotkeyNet. I designed an entirely new language (implemented in HotkeyNet 2) to replace the old one.

http://www.hotkeynet.com/hkn2/ref/LanguageOverview.html

http://www.hotkeynet.com/hkn2/ref/Functions.html

http://www.hotkeynet.com/hkn2/ref/Types.html

Let me give you an example of the bad decisions I made when I designed HotkeyNet's language. The worst one was not having any end-of-block markers. It makes the language terribly confusing. The language *does* have blocks, and they *do* nest, but since there are no end-markers, the language imposes the block structure according to precedence rules which are described under "Blocks and nesting" in the instruction section of the website. I thought this would be simpler than requiring the user to mark blocks, but in fact it makes things harder because the user has to understand the precedence rules.

I did this as an experiment because I had never seen a language with this kind of design, and I was curious to see how it would work. Well, it works very badly! Now I know why nobody designs languages this way! :)


I don't know if I got a bad example script or if something has changed in HotkeyNet since this was written, but the <PassThrough> in the SendMasterAndSlave template throws the following error:
This is a good example of how a language's syntax can create confusion

I'll explain the whole thing from the language designer's perspective, and you can decide if this was one of my mistakes.

What does PassThrough really do? It tells the keyboard hook not to swallow the trigger event. Therefore it's a directive to the keyboard hook.

Every other keyword you write in a defintion (including If) gets executed by the interpreter after the hook finishes. PassThrough is a different kind of keyword. It's the only directive in the entire script language that gets executed by the hook.

The hook finishes before the interpreter begins. Therefore, PassThrough must execute before everything else you write in a hotkey definition.

In particular, PassThrough must get executed by the hook before the interpreter evalutes If.

Originally I thought users wouldn't have to understand this. I thought I could hide these facts from them and make things simpler. But during HotkeyNet's beta test it turned out that PassThrough was a major source of confusion.

So I made a small change to the script language to try to convey the idea to people that PassThrough always executes earlier than everything else.

I added a syntax rule -- which is enforced by the parser -- that requires PassThrough, if it's used at all, to be the first statement in a definition.

I thought this was a clever solution to the problem because everybody assumes scripts execute from top to bottom, and the parser would automatically force them to realize that PassThrough executes first. They wouldn't have to read this in the documentation. The parser would force them to do it correctly by means of an error message.

But as you can see from your own experience, this didn't work. You thought you encountered some sort of problem. Perhaps it would have been better if I had made a completely different syntax for PassThrough.

[Nomahd]

Thanks. I appreciate that. It's not the worst program I ever wrote, but it's much less good than its replacement will be if I ever finish it.

You're welcome! Even if your program is not perfect, and what program is? It's still a great program and I'm very sure you had a lot of sleepless nights working on it. ;)



Let me give you an example of the bad decisions I made when I designed HotkeyNet's language. The worst one was not having any end-of-block markers. It makes the language terribly confusing. The language *does* have blocks, and they *do* nest, but since there are no end-markers, the language imposes the block structure according to precedence rules which are described under "Blocks and nesting" in the instruction section of the website. I thought this would be simpler than requiring the user to mark blocks, but in fact it makes things harder because the user has to understand the precedence rules.

I did this as an experiment because I had never seen a language with this kind of design, and I was curious to see how it would work. Well, it works very badly! Now I know why nobody designs languages this way! :)

Yes, I discovered this limitation when I tried to nest <If> blocks. <DoHotkey> allows a workaround, but there is definitely room for improvement in this area.



What does PassThrough really do? It tells the keyboard hook not to swallow the trigger event. Therefore it's a directive to the keyboard hook.

Every other keyword you write in a defintion (including If) gets executed by the interpreter after the hook finishes. PassThrough is a different kind of keyword. It's the only directive in the entire script language that gets executed by the hook.

The hook finishes before the interpreter begins. Therefore, PassThrough must execute before everything else you write in a hotkey definition.

I added a syntax rule -- which is enforced by the parser -- that requires PassThrough, if it's used at all, to be the first statement in a definition.

Which explains the error. The <PassThrough> was inside of an <If> block and was also not the first statement in the definition.


I thought this was a clever solution to the problem because everybody assumes scripts execute from top to bottom, and the parser would automatically force them to realize that PassThrough executes first. They wouldn't have to read this in the documentation. The parser would force them to do it correctly by means of an error message.

But as you can see from your own experience, this didn't work. You thought you encountered some sort of problem. Perhaps it would have been better if I had made a completely different syntax for PassThrough.

Yeah, there's probably room for improvement there. I can think of some situations where it would cause some problems. Like if someone only wanted to use <PassThrough> if certain conditions existed. Which would mean the PassThrough would have to be placed inside of an <If> block. Unless <DoHotkey> would allow a workaround for this as well. I haven't faced this particular situation yet so I haven't had to try it.

But still, every language has it's limitations. Some people will never hit the limitations of some languages. It depends on how advanced they are and what they are trying to accomplish.

For example, I found a limitation of AutoIt a few years back. I discovered that performing a DLL call took a LOT longer than it did in C++. Most users would never even notice since the difference was only a few milliseconds. But when you have an algorithm that calls a DLL 10 million times those few milliseconds multiply the overall time it takes to execute by a lot. If the DLL call in C++ only took .1 ms and in AutoIt the call took 10 ms, that means it took 100 times longer to execute!!!

I don't know the exact time differences, that's just an example. But basically it took like 2 hours to execute this algorithm in AutoIt but only like 10 minutes in C++. I can only assume the reason is because AutoIt is a language coded from C++. So doing the call in C++ is a straightforward call, but in AutoIt it performs other actions behind the scenes which add to the time since it executes more lines of code.

So the language needs to fit the situation. I loved AutoIt. I found it very fun to use. But It couldn't be used for everything.

HotkeyNet is the same thing. It works great with basic scripts and in some advanced situations. But it has it's limitations. Your new language will be much better I am sure. But even that language will have it's limitations. Whether or not people actually hit those limitations remains to be seen. But I would say that some probably will.


I'm a user of languages, not a writer of them. So some of my opinions here could be wrong. I only speak from my own experiences. I would have to do a lot of research to even know where to begin writing a language.

[Freddie]

Yeah, there's probably room for improvement there.... PassThrough would have to be placed inside of an <If> block...
I guess I wasn't clear. I can't change the fact that PassThrough must execute before anything else in the hotkey. This is a consequence of the fact that the keyboard hook must return to the OS as fast as possible. It's a limitation imposed by the nature of PassThrough (what it does at the system level).

The only thing I can control is how this fact gets communicated to the user.

There are three channels through which I can communicate this fact: documentation, language syntax, and error messages.

You learned about the fact from an error message.

What I was discussing was how I chose to communicate the fact, not the fact itself, which is a given.


I discovered that performing a DLL call took a LOT longer than it did in C++. Most users would never even notice since the difference was only a few milliseconds.
C++ programs and AutoIt programs are different sorts of things. They work in completely different ways. C++ programs are very, very, very much faster.

C++ programs are compiled and linked. Compiled means native code, code that executes immediately inside the CPU. Linked means the different pieces of code exist in the same process and can call each other through CALL instructions executed by the CPU.

AutoIt programs are nothing like that. They are interpreted programs. They aren't native code. They don't consist of instructions that execute in the CPU. They don't have a process. The process belongs to the AutoIt interpreter. These facts alone (apart from DLLs) make execution many times slower.

With C++, the DLL gets loaded into the process's address space once, and from that time onward, your code can call the DLL as if the DLL was an integral part of the code (which it is after it's loaded).

That doesn't happen with an AutoIt program because your program isn't the same kind of code as a DLL. They can't be linked directly. What happens is that the AutoIt interpreter (not your program) asks the operating system to load the DLL into AutoIt's address space. Then AutoIt calls your requested function in the DLL through a bunch of intermediary code which is much, much, much slower than the equivalent operation in C++.


But basically it took like 2 hours to execute this algorithm in AutoIt but only like 10 minutes in C++. I can only assume the reason is because AutoIt is a language coded from C++.
That's not the reason. Both languages are written in C++. (In other words, C++ compilers are written in C++. They have to be written in something.)


I'm a user of languages, not a writer of them. So some of my opinions here could be wrong. I only speak from my own experiences. I would have to do a lot of research to even know where to begin writing a language.
Designing a language and implementing its interpreter (or compiler) is one of the most interesting, educational things a programmer can do.

It's also a lot of fun to create your own language and use it.

Writing a language is harder than most things that self-taught programmers do for fun, but it's not *that* hard. It's within reach of many programmers. If it seems interesting to you, i urge you to give it a try.

[Nomahd]

I Think I'm going to give Mojo a try. I just hit my first snag with Input Director and I can't find a way out of it. The problem is a deal breaker for me unless I have no other option to get this working.

To keep it simple I'm going to call my main computer the Master and the other computer the Slave.


The problem:

I tried to setup HotkeyNet to allow my Ventrilo Push-to-Talk hotkey to always activate PTT on the Master no matter what computer currently has the focus of my Mouse/Keyboard. This way I can still talk while my Slave has focus and also not have to use a 2nd keyboard. The Master is where Vent is located.

PTT works fine while my Master has focus.

PTT does NOT work when the Slave has focus.

PTT does work from the Slave if I use the Slave's keyboard and only if the Slave is not the focus of the Master's Keyboard/Mouse.

HotkeyNet shows no errors at all and it shows a successful send/receive from both HotkeyNet windows even when it doesn't work. This leads me to believe it has something to do with Input Director blocking the input.

Is what I am trying to accomplish possible with your Mojo?


Just to be thorough, this is what I'm using in the script on both machines:

<Label Vent 192.168.0.110 SendFocusWin>

//-----------------------------------------------------------
// VENTRILO PUSH TO TALK HOTKEY.
//-----------------------------------------------------------
<MovementHotkey Oem3>
<SendLabel Vent>
<Key Oem3>Naturally, I change the IP to Local for the Master's script. But I am certain this code is not the issue. It works fine if I use seperate keyboards and don't change my Master keyboard focus to the Slave.

I've also tried setting up the PTT macro using Input Director but it doesn't work correctly.

[Nomahd]

So, what happens when the master mouse cursor is moused over to the slave, and you trigger the PTT hotkey? HotkeyNet generates a keyboard event on the master PC. Input Director prevents programs on the master PC from seeing the event. Therefore Vent doesn't see the event. Then Input Director generates an equivalent keyboard event on the slave.

If that's what is happening, Input Director is just doing its job.

That was my assumption. However, if it prevents the Master from seeing the event, why does HotkeyNet on the Master still see the event? HotkeyNet sees the event and responds accordingly. That is where communication breaks down.

Also, WoW on the Master stills sees the events when I'm on the Slave. Otherwise FTL would be useless over a network. So it obviously doesn't prevent all events. Something is different in the case of Vent.

Will I be able to accomplish PTT in this manner with Mojo or am I going to have the same problem?

[Freddie]

Please ignore this -- this was a replacement for my last post but you already replied to the last one.


I tried to setup HotkeyNet to allow my Ventrilo Push-to-Talk hotkey to always activate PTT on the Master no matter what computer currently has the focus of my Mouse/Keyboard.
If the master mouse is over on the slave PC, Input Director's job is to make that impossible. It sounds like Input Director is simply doing its job.

Here's the situation. The master mouse cursor is over on the slave PC. You press the PTT hotkey. HotkeyNet synthesizes a keyboard event on the master PC. This is the exact same thing as if you had pressed a key on the master keyboard with your finger. Input Director sees the keyboard event. Because the master mouse cursor is moused over, Input Director's job at that moment is to redirect the key press to the other PC.

When Input Director (or any KM program) redirects an event, it actually does two things. (1) It prevents programs on the local PC from seeing the event. (2) It synthesizes an identical event on the remote PC.

Input Director does those two things. That's its job. As a result, Vent on the master PC doesn't see the output from HotkeyNet's hotkey.

[Nomahd]

I understand how it works.

I don't understand why World of Warcraft can still receive hotkeys from the Slave, Notepad can receive hotkeys from the Slave, but Ventrilo cannot.

Why block events to Ventrilo but not to other programs? What is different about Ventrilo?

Input Director also allows hotkey macros, but they can't be held down. Otherwise I could do it that way. Does Mojo have the ability to create hotkeys that can be held down and sent to any system?

[Freddie]

This post crossed your last one again.


That was my assumption. However, if it prevents the Master from seeing the event, why does HotkeyNet on the Master still see the event? HotkeyNet sees the event and responds accordingly. That is where communication breaks down.
That can happen for two reasons. One reason would be that HotkeyNet is getting its keyboard input from a lower level in the operating system's keyboard processing chain than Input Director. The other reason would be that both programs are getting their input from the same place (i.e. a low-level keyboard hook) but HotkeyNet is installing its hook earlier in the chain than Input Director so it sees the keystrokes first.

You can test whether the second explanation is correct by launching the programs in the opposite order. This will change the order in which their keyboard hooks see keyboard input.

It's possible that all three programs (including Vent) receive their inputs from low-level keyboard hooks. In that case, you can change this behavior by launching Vent and the other two programs in a certain order. Vent would have to be launched either first or last -- I can't remember which.


Also, WoW on the Master stills sees the events when I'm on the Slave. Otherwise FTL would be useless over a network. So it obviously doesn't prevent all events. Something is different in the case of Vent.
I'll answer this below.

[Freddie]

I understand how it works.

I don't understand why World of Warcraft can still receive hotkeys from the Slave,
Probably because you're using SendWinM or SendWinS in those hotkeys. Those send modes don't generate keyboard events. Those send modes communicate directly with the WoW client and tell WoW that a keyboard event occurred even though it didn't really. Input Director has no way to know that HotkeyNet is sending those messages to WoW.

Unfortunately, those send modes probably won't work with Vent because Vent is intercepting keystrokes on a system wide basis, which means it's probably receiving its keyboard input with either a low-level keyboard hook (see my last post about launch order) or else it's using an operating system registered hotkey.


Does Mojo have the ability to create hotkeys that can be held down and sent to any system?
The old Mojo never got beyond its first two months of development. It's just a bare bones KM program. It has a really nice hotkey entry window (one of the best pieces of programming I ever did in my 30 year programming career) but it can't do what you describe.

[Nomahd]

That can happen for two reasons. One reason would be that HotkeyNet is getting its keyboard input from a lower level in the operating system's keyboard processing chain than Input Director. The other reason would be that both programs are getting their input from the same place (i.e. a low-level keyboard hook) but HotkeyNet is installing its hook earlier in the chain than Input Director so it sees the keystrokes first.

You can test whether the second explanation is correct by launching the programs in the opposite order. This will change the order in which their keyboard hooks see keyboard input.

Input Director is always run 1st on both systems because it's started before I even log in on both of my systems. This allows me to never touch the Slave keyboard for any reason, even to log in. I can use the Master's keyboard to enter my user password in my Slave.

After logging in I start up HotkeyNet then launch WoW using the specified hotkey. Then I usually alt-tab out to start Vent.


It's possible that all three programs (including Vent) receive their inputs from low-level keyboard hooks. In that case, you can change this behavior by launching Vent and the other two programs in a certain order. Vent would have to be launched either first or last -- I can't remember which.

I will try launching HotkeyNet and Vent first and see if that corrects the problem. This is why I'm asking you. I know nothing about keyboard hooks.

[Freddie]

Based on what you told me, if this could work at all, you're already launching them in the correct order.

[Freddie]

I just looked at Vent. You have "Use DirectInput to detect hotkey" unchecked, right?

[Freddie]

You're running all three programs as administrator, right?

[Nomahd]

You're running all three programs as administrator, right?

Sorry, in the middle of cooking... Yeah, on my Vista x64 box. Don't need to on my XP x86 box.


I just looked at Vent. You have "Use DirectInput to detect hotkey" unchecked, right?

I did earlier, it's not now. It didn't seem to have any effect whether it was enabled or disabled. Maybe it will after I restart my systems and not have Input Director startup automatically.

I need to finish cooking then I'll be back and testing some more.

[Freddie]

If that option does what its name suggests that it does, and if it's checked, then I'm thinking Input Director will most likely stop Vent from seeing the keypress no matter what the launch order is.

[Nomahd]

I unchecked it after restart and it had no effect. I started Input Director last but achieved the same results. I forgot that HotkeyNet was targeting a direct window in the cases other than Vent which explains why they still receive the events. Targetting Vent directly has no effect, probably because it reads keys in the way you stated above. It's starting to make sense.

But while cooking I had a new idea...

I can move Vent to my Slave and use HotkeyNet to send the hotkey to the slave instead. The Slave keyboard is not blocked while the Master has the focus of my Master keyboard, so Vent should still receive the event, and when my Slave has the focus of my Master's keyboard it should send directly anyway. I think this will work... there's only one way to find out. I don't care which system I have to use for Vent so long as I can talk while using either.

[Freddie]

I was thinking the same thing. Good luck!

[Nomahd]

I was thinking the same thing. Good luck!

Thanks!! I got it to work on the Slave. But I couldn't use Oem3 for some reason. I'm going to look into more, but at least it's working.

[Freddie]

Grats!

[Nomahd]

Now I have it working with Oem3. I forgot to run Vent as admin on my Slave... ;)

[Freddie]

Great. :)