http://mojoware.org/art/active-window-tracking.gif
Printable View
I'm guessing that this is almost entirely for "same box" multiboxers? Not one-client per PC setups.
Maybe somebody who asked for it can explain. I don't know why people like it.Quote:
Originally Posted by Fursphere
Does it only track WoW windows or does it track all other windows as well?
All windows.Quote:
Originally Posted by Akoko
This is a feature of Windows not Mojo. Mojo is just turning it on and off.
if you have only 1 window per pc and they are all maximized then you don't care about this feature, otherwise you'll love that you don't need to click for the window to get the (unbroadcasted) keys
there is a bug: when you click either of the 2 radio button set; it unsets the other one
gimme build 20 :-)
Works fine for me.
Windows 7 Pro. I only enabled "window tracking" - its pretty cool even for basic Windows stuff.
That's strange. I played around with it for about 10 minutes before I posted it and this bug wasn't there.Quote:
Originally Posted by Moorea
Maybe the bug is happening because of optimization in the release build. I was testing with a debug build. Well I'll look at a new debug build and see.
Thanks.
OK, I got a different bug.
Setting it back to "system defaults" doesn't turn it off - you have to click "off" then apply it. Then it'll "stick".
It messes with the Taskbar though - makes it hard to use it.
It's fixed but I'm going to change the window a little bit before i post it. about 20 min.
That's not a bug. "Use system setting" really means "Mojo doesn't do anything." You won't get your system defaults back till you reboot.Quote:
Originally Posted by Fursphere
Maybe there's a better name than "Use system defaults" for those buttons.
Edit: The problem is, Mojo has no way to know what your system defaults are They are probably in the registry but Microsoft doesn't document them (at least I don't think it does) and I don't lke using undocumented features.
Edit: Maybe just this once I'll use undocumented settings. :)
Build 20 is up.
Fur, you're right, that "Use system setting" stuff doesn't cut it.
I'll have to figure out tomorrow what to do about it.
It's amazing how tiny things like this turn into problems. :)
This whole feature should have taken 45 minutes. :)
Here's my proposed solution for "Use system settings."
When Mojo starts up, it will record the settings that were in use before it started.
If you select "Use system settings," Mojo will restore those settings.
Maybe the caption should say "Use prior settings" or something like that.
Maybe the caption should say "Restore something or other."
"Restore original settings."
"Use existing settings."
"Use current settings."
Would it be better to store the settings that were in use whenever the user changes the setting off of "Use system default", rather than when the program starts?Quote:
Originally Posted by Freddie
That would prevent conflicts if the user changed the Windows setting between starting Mojo and changing the setting in Mojo.
Maybe I'll do it that way.
I don't mind having to reboot to get back to system default if it's hard to remember and it wouldn't be the same (ie it would change something from default) - don't sweat that part too much
now the radio buttons do all work ! thx a lot !
small suggestion: add an "apply" button so the user can experiment with the settings without having to click "ok" and reopen the dialog between each try
thanks a lot for that feature and quick turn around !
another minor nit picking (but I wouldn't sweat it either) the raise window part doesn't work if the first on is on off (so I guess in theory it should be grayed out in that case)
[I know it's not a mojo feature but you're doing the UI for microsoft :-) ]
minor unrelated bug report: I tried to assign NumLock to toggle broacasting on/off so I get some visual feedback on my keyboard (pending the overlay or semi transparent status window :p) but if I do it eats the event and my keyboard light doesn't toggle anymore
(tried to put both nothing and "when numlock is on" which didn't work; and pressed "numlock" which worked (toggles it in mojo) but then doesn't toggle the light on my keyboard anymore
another interesting side effect/bug of this new feature:
when I mouse to the other PC's screen, mojo comes to the foreground on my main PC, even if the mouse doesn't at all go over mojo's window while moving out of the 1st pc' screen (seems like when you hide the local cursor; you put it maybe on mojo's and that raise that window - can you leave it at the last window it was in on the original computer screen?)
sorry for all the issue reports :-) don't be discouraged :-)
To save time, I've been omitting Apply buttons from all settings boxes. I'll add them in at some future time.Quote:
Originally Posted by Moorea
Maybe I'll add them today since you reminded me.
I agree. The problem is that if the "do nothing" buttons work that way, it's hard to give them names that make their function clear. But when I woke up this morning, a possible answer popped into my head:Quote:
Originally Posted by Moorea
-- Do not change
-- Turn off
-- Turn on
During mouseover the local cursor has to be handled in a pretty complicated way. It's not just parked. It's moving, it's on top of a special invisible window, it's constantly moving away from the center of the screen and getting recentered, etc.Quote:
Originally Posted by Moorea
Edit: I just looked at the source code and this doesn't seem to be true. I think I was remembering a different version I wrote earlier. I'm not sure why this problem is happening.
I'll try to figure out a way to fix this.
I'm not discouraged. I'm glad you're noticing all this stuff.Quote:
sorry for all the issue reports :-) don't be discouraged :-)
You probably feel like you're dumping work on me but my reaction is the exact opposite.
My reaction is, "Oh good, I don't have to spend time testing, because Moorea will tell me about errors."
I think that's important. I"m glad you pointed it out.Quote:
Originally Posted by Moorea
If I don't change that, people will report it as a bug, because they'll say "raise window" isn't working. I'll change it.
I know why this happens but I don't know how to design the program to deal with it.Quote:
Originally Posted by Moorea
When a keystroke triggers a hotkey, Mojo takes some action. Then it has to decide whether to pass the keystroke to the operating system so the OS and other applications can take whatever actions they would normally take if the keystroke had not been redefined as a hotkey trigger.
(I said the other day that I don't like the word "pass" but in this case, Mojo really is allowing something to pass.)
By default, Mojo doesn't pass hotkey triggers to the operating system. Triggers have been redefined by the user to be commands to Mojo, and Mojo processes those commands, and that's the end of it.
When this happens, users often say that the hotkey program "swallowed" their keystrokes. This isn't right because they redefined the keystrokes themselves, and the keystrokes got processed.
But it's convenient to say the keystrokes get swallowed (you said eaten) so I'll say "swallowed" too.
Now, the thing is, sometimes the user wants the trigger to get swallowed and sometimes he doesn't. The way I handled this in HotkeyNet was with a keyword, <PassThrough>.
You're familiar with HotkeyNet so I 'll illustrate this with two examples from HotkeyNet's script language. We're talking about the difference between the two following hotkeys:
The first one would have the side effects you've reported here. The second one would not.Code:<Hotkey NumLock>
<SetWindowBroadcast toggle>
<Hotkey NumLock>
<PassThrough>
<SetWindowBroadcast toggle>
That's fine for HotkeyNet because everything's defined by the user in a script. But Mojo's supposed to be easier to use.
So the question here is, how to handle the issue of passthrough or not passthrough.
I would like to hide this decision from the user but I can't think of any way to do that, that would really work.
The only thing that occurs to me is to add it as a checkbox on the Set Trigger dialog. In this case, with this hotkey, when you make the trigger, you'd check "PassThrough."
Numlock Light Toggle as a visual indicator:
- A visual onscreen overlay will solve this. So I feel the numlock issue should be pushed aside as something else is already planned. I don't think creating two workarounds for one "root" issue is a good way to spend time.
(about numlock example)
cool so maybe add checkbox to the dialog "with pass thru" option ?
that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?
(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)
(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)
I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?
ps: Fur: I agree a visual overlay would fix my numlock issue but I suspect eating up the key in all cases may have other consequences and so the option to look/peek instead of consume the event is probably valuable for other advanced use - minor though I'd agree - I'd rather get some basic DNP and click broadcasting than this (in term of order)
True. Can you clearly define the issue / request and add it to the FAQ Request post? :)Quote:
Originally Posted by Moorea
It's really a question about passthrough not numlock. It just happened to get noticed for the first time with Moorea's numlock hotkey.Quote:
Originally Posted by Fursphere
It has to be decided sooner or later because it's going to affect a big percentage of user-defined hotkeys.
It's not a work around. It's a choice of two ways that hotkeys can work and the choice has to be provided.
I think I added them in
http://www.dual-boxing.com/showpost....12&postcount=2
and a new
http://www.dual-boxing.com/showpost....12&postcount=3
Unless somebody thinks of something better.Quote:
Originally Posted by Moorea
"When numlock is on" is a state, not an event. Only an event can trigger a hotkey. You have to do something (press a key) to make something happen. Which key do you press? That's what the top section is for.Quote:
that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?
I'm not sure I understand. Are you saying you define the trigger NumLockOn A?Quote:
(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)
That means, "If I press A while NumLock is on, Mojo should do the action."
There's no way to infer anything about passing from that trigger. Two people might define hotkeys with that same trigger. The first person might want A to pass, and the second might want the opposite.
I'm looking at the source code and it looks like the invisible window isn't even a factor. I'm not sure why this is happening.Quote:
(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)
I think probably it would be better if I track bugs myself because users have no way to know whether something is a bug or unfinished work.Quote:
I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?
If you include unfinished work in the bug list you would immediately have dozens or maybe hundreds of items and it would only make the program look bad.
Would it be possible for it to only track WoW windows (and maybe Mojo window(s))? I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!
Active Window Tracking doesn't distinguish one program from another but you might be able to get the effect you want some other way.Quote:
Originally Posted by Akoko
For example, you could set all your WoW windows "topmost" (always on top). That way your browser wouldn't cover up a WoW. That's not quite what you want , though.
Technically speaking, YOU are mousing over internet explorer. If you don't want to mouse over IE - don't put the mouse cursor there. :)Quote:
Originally Posted by Akoko
Bah technicalities. This calls for one of those jumping mice. :)Quote:
Originally Posted by Fursphere
Build 21 is up with bug fixes and minor changes requested in this thread.
-- I fixed (fingers crossed) Mojo rising to foreground during mouseover.
-- Added progressive disclosure to Active Win Track settings.
-- Changed names of fields on Active Win Track settings.
-- I couldn't fix the crash reported by Moorea but I wrapped the crash location in an exception handler. From now on, when that bug happens, the program should display a message box and keep going. If people can figure out what makes the message box appear, that would be great.
I'm not entirely sure how it's handled, but Keyclone has a "Focus Follows Mouse" option that makes the mouseover'd WoW the focused window without clicking, and it doesn't use the global Windows setting, AKA it doesn't set the focus to non-WoW windows when they are moused over.Quote:
Originally Posted by Freddie
I'm not sure if you'd be able to use the same system as Keyclone to handle the active window tracking in Mojo or not (or even figure out how they handled it), but figured I'd mention it anyways. :)
I guess one way would be, when the OS calls the mouse hook:Quote:
Originally Posted by TheFallenOne
1. Call a Win32 function called WindowFromPoint that tells us which window the cursor is in.
2. Check whether that window is on our list of WoWs. (If a program doesn't maintain a list of WoWs, it could call a function that gets the window class name and compare that to WoW's.)
3. If the answer is yes, call SetForegroundWindow.
I could add that to to program as an option. It's just a few lines of code and I don't think it would affect performance noticeably.
I found a small bug/issue with the latest (21) build:
I changed my network settings for 2 laptop to use ICS (internet connection sharing) [ethernet link between the 2 and 1 of them only on wireless - this is to see if latency is even smaller that way when KMing] and the slave computer was showing as a black screen on the master one (and the master not at all on the slave) until I went into advanced settings and set the master (the one on the computer with the internet connection) to use the private IP from ICS instead of system default - I think Mojo should be smart enough to guess that it should check both sides if I have multiple network interfaces - some explanation of the colors would help too (what does black and yellow mean exactly ? just seems that blue = good and the others are not so good but what exactly?)
another related issue: if I start a mojo on the other side of the interface that one shows yellow for the middle pc on the outside one (when the ics one works) or if I get back to default setting, the master and 3rd outside work but the one behind the ics is black...
Anyway to have all the PCs showing up as well as (maybe) proxying automatically so the one outside sees the one inside too - through the one it would see ?
I think for the first problem you just need to listen to all interfaces - the proxy part can wait
Mojo's connection stuff isn't finished yet. With the current build, you if you make a change like that you need to shut down both Mojos and then start them both.
Did you do that?
Edit: For all problems of this type, please let me know if you shut down all Mojos and restarted all of them before you saw the problem. It makes a big difference to me.
The color codes aren't finished. The current scheme is temporary. Blue means two socket connections between the computers; purple means one socket connection (they are connected in one direction but not the other); black means no connection.
yes I shutdown all mojos in between each try/change as I noticed that exiting 1 doesn't change the status on the other (doesn't detect the deconnection)
Mojo does listen on all interfaces. Please let me know if you shut down all Mojos and restarted them.Quote:
Originally Posted by Moorea
Edit: Sorry this crossed your last post.