Need to solve this erratic typing behavior once and for all

Which computer in your setup is the primary?

It is not possible for an application on the secondary to take focus from the primary.  The only way you can switch to a secondary is via a hotkey or via moving the mouse onto the other computer.

Agree, it is not happening that way.  In my above example PC2 is the primary.  So when in the secondary (PC1) after some number of seconds of typing away normally, it goes haywire.  Its focus is being distracted by the PC1 (primary). 

I have 4 computers.  Tested this with only 2, 3 and then 4.  Removed anti-virus, etc - stopped firewall - all the known recommendations made by the Multiplicity folks and others on the boards. 

Issue is something is taking that focus away from the secondary.   That is the challenge for the developers of this software.  This is a known issue for many years that folks have described and the developers bat it away trying to say something else is to blame.  No, it is (unfortunately - sorry) the developers not understanding all the environmental factors.  Other software competitors to Multiplicity do not have this issue.  I prefer Multiplicity but can't praise it and always look for other solutions because of this one massively annoying problem.  Drives everyone crazy.  If it could be solved, then Multiplicity would be many levels above the competition.

Right now I am trying to see if the issue is tied to the following value in ForegroundLockTimeout

Ran across this article from 12 years ago (I know I know) https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc957208(v=technet.10)?redirectedfrom=MSDN

That says the default value should be 200000

(HKCU\Control Panel\Desktop\ForegroundLockTimeout default should be 200000)

I found my value at 0 (zero)

Will hopefully find out soon enough if this solves it.

In which case, can the developers please look to see if something in your program is inadvertently triggering it to move to zero?  Even if not, set your software on the primary computer to set the value to 200000

Will get back on results ... preliminary is that this might be it ... for last few minutes when I mimic the same conditions as I have previously, I cannot reproduce the erratic behavior.

Oh well ... so much for that idea ... it didn't last.  Any other ideas would obviously help us all help the developers.

And here is the other thing ... the mouse stays on the secondary ... so when I say "focus" it is NOT stealing the mouse focus ... it really is stealing the "keyboard" focus

Now granted, you type where you click but somehow even if you have the window focus and mouse focus on the secondary maintained, the "keyboard" focus disappears if you know what I mean ... it stops typing in the secondary unless you go back to the primary and click on a window there

From the description it sounds like the keyboard hook has been blocked by something and silently terminated by the OS.  This is undetectable to the owning application.  The keyboard input would then go to the primary whilst the mouse would continue on the other computer as that hook remains in place.

Given mouse and keyboard share the same input queue in MP, it would imply the foreground application may be a factor in stalling the hook rather than code inside MP.

I will personally check the code next week to see if there is anything that could possibly stall inside the MP code.

If you are not using MP 3.55 on the primary I recommend you upgrade as it had changes for how certain things worked.

It would also be interesting if you changed the following value : 

HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout  This would be a time in ms and you may have to create the key.

Take a look at X-Mouse Controls by Joel Purra

https://joelpurra.com/projects/X-Mouse_Controls/

I downloaded the app ... I activated "Activate window tracking" and set the Delay to 100 ms

When I installed it just on the secondaries, it still did not solve the issue but once I installed it on the primary too, problem has been gone for about 45 minutes so far ... will keep assessing.  If this really rectifies it, it should be investigated.

I will try out your solution tomorrow and get back to you ... for now it appears X-Mouse has stopped the lost keyboard focus

hi Neil,

Here are results.

Yes I am using the latest Multiplicity 3.55 on all boxes.

I stopped X-Mouse.

I created the key HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout  and set the value to 5000 suggested by several sites.  At first it seemed to work but on reboot, the erratic behavior remained.

Since yesterday evening, X-Mouse has solved the issue.  The only downside is if I need a focus on a window I have to click on the window taskbar but this is not a real issue given what it has solved.

I recommend you go to Joel Purra's website ... he has available the source code to X-Mouse.  Hopefully by reviewing it you can identify other registry steps.  I am willing to be your beta tester.

Thank you,

Nick

Unfortunately the forums are not exactly full of reports of anything like this and neither have we been able to reproduce anything like this which strongly points to there being something else other than a stock MP + firefox install being a trigger for this.

It is worth mentioning that when you are controlling a secondary, the focus on the primary will remain on the foreground application on that computer as well.  Both computers have their own active windows.  Multiplicity simply intercepts the input and passes it over to another computer.  Multiplicity is designed to carefully prevent the loss of foreground window focus when switching between computers.  To do otherwise would be incompatible with many games.

My gut feeling here is something on your computer is intercepting / blocking keyboard hooks.  The prime suspect would be something thats trying to protect passwords / credit card entry from being captured by something running on your computer.  I could well see a security application blocking keyboard hooks when a webbrowser is foreground and that would lead to the symptoms you see.

This would also explain why X Mouse would help as it would switch focus away from firefox.

We have made a new build with a change in how keyboard input is queued just in case and I think Sean may be in contact with you shortly about that, but it would also be very useful to know what firefox addins you run and also what security software.

Hello,

Sorry to hear you are having trouble.

That is nearly impossible, understanding all the environmental factors, as each person's PC is unique in endless ways (apps, settings, security, health). Were any notable number of others having this issue in demonstrable/repeatable, ways, we would have more to go on but that is just not the case.

I say this as the following new build has some hook changes but the expectations should be low for the issue you are having - again, one we still believe is likely related to something else (security app \ setting being a prime candidate).

https://cdn.stardock.us/support/uploads/Multiplicity_3.56-j50-Setup.exe

Again, you are going to want that installed on each PC.

Let us know.

Sean Drohan
Stardock Support Manager

hi Sean,

Thank you.

I have tested the beta you sent.

Overall much better ... the only time it reverted to the primary (when my mouse was on secondary) was a very rare hard test I did.  Otherwise, it appears to have mostly resolved the issue.

A big thank you.

If you could incorporate in future releases it would be appreciated by more folks than you realize.

Thk u

Nick

Sorry but issue is back.

The inability of Multiplicity to keep the keyboard focus where the mouse focus is, is a failing.  Yes I hear you re different environments for different users, but this the ability to maintain those two foci on same secondary box is straightforward requirement.  Post me when you can do this.  Thank you.

If we knew what you have that is causing it, we would.

It's about time to try a clean boot on each PC:

https://forums.stardock.com/486104/multiplicity-support-faq#cleanboot

Sean Drohan
Stardock Support Manager

Sorry.  Over last 4 decades, I have found anyone asking for clean environment and/or reinstalls to not understand their own product.  Your coding is not robust if it cannot handle what has been described.  To patch very one off situations I would discourage, rather you address the key functional issue.   Ensure you program does interval time slices that checks and as necessary resets the focus of keyboard/mouse to be maintained at same box.

I am going to have to jump in as I don't think you fully understand the situation here.

Multiplicity sets a hook upon switching to another computer.  This hook remains in place and based on the test with that new build, the hook remains in place.

Should input no longer go to Multiplicity it cannot relay it to another computer.  This can only happen if something else on the computer is interfering with the normal operation of Multiplicity.

The most likely cause is something 'protecting' your computer from keyboard hooks and I suspect given the mention of browsers that some sort of browser add-in is the issue here (or security product).

Interval time slices (i.e. a timer) would do nothing for this if the app is actively preventing a hook from remaining.

This is why we need to know what is on the primary PC in question and ideally try to narrow down the cause.  Once we know that we can hopefully reproduce this in house and from there diagnose the root cause and see if there is anything we can realistically do.  As an example it is known that ZoneAlarm prevents Multiplicity input from impacting it on a secondary.  There is nothing we can do about that one because it is actively checking input comes from the local keyboard.

So in short, currently we have no useful information to work on hence the need for more information on the environment and ideally (if you are willing) to be able to narrow down the culprits.  Once we can repro it, we can fix it.