[HotKeyNet] Sending keystrokes from slave to master?

[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.

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.

[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]

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?