'go' command doesn't work properly

[tgice]

Hi, I've been trying to use enso-portable in Win 10 64 bit for awhile, on a fresh install, and am having problems with the go command and even the open command in a similar way.

If I do a "go ..." command to switch to another window, it works, but only partially, the focus generally (maybe always) stays on the window that was foregrounded, but on the taskbar, the new window that should have focus will highlight (it may flash a bit first, but then just stay highlighted) ... oh that's weird, as I was testing this a little more, it seems like it generally /does/ work properly if the new target window was minimized, but if it's not, then the above symptom occurs.

I should also mention that I have UAC disabled, so everything's basically running elevated (as Administrator), by policy on my work domain policy. Don't know if I'll be able to reasonably work around that or not.

Any ideas on what this might be or how to workaround it or fix it in the code?

Thanks,

jl

[GChristensen]

Any ideas on what this might be

A set of restriction on SetForegroundWindow API. https://msdn.microsoft.com/en-us/library/windows/desktop/ms633539(v=vs.85).aspx

how to workaround it or fix it in the code?

That must be extremely tricky.

[tgice]

I know this always used to work fine in the past, possibly on pre Windows 10 platforms for me, but I could've sworn that the original Enso, which still kind of runs okay on Win10 also worked most of the time at least with the go command.

Are you aware of when this changed, and if there's any hope on this?

I can of course understand why MS would want to prevent bad behaving software from stealing the focus from a foreground window, but surely if this behavior /used/ to be allowed, they would come up with some method (such as a user indicating that a certain application /should/ have this right) to allow this.

[GChristensen]

Fixed in Windows 10

[tgice]

Thanks so much for working on this again! If this version contains all of your latest changes, including those from earlier today (6 hours ago):

https://github.com/GChristensen/enso-portable/releases/download/v1.0.10/enso-portable-0.1.10-py27.zip

Then I'm still experiencing a few problems.

Firstly, the 'go' command definitely seems to be working better than it did before. I think in most situations, if I go to a window (unless it's on a different virtual desktop, or if the target window is an Administrator-permissioned window or if I'm focused on an Admin window [then Enso won't even pop up on an caps lock keypress]), the window now get properly focused and foregrounded.

I still am seeing this troubling behavior though so far in my first hour or so of testing:

Sometimes, but not always, when I complete a go, the cursor is still left behind in the last focused window, even though the intended target new window is foregrounded. This can happen even if the new target window pops in front of the old, the cursor will still be back there hiding!

E.g., one situation that seems to come up reliably is if you open two Command Prompts (not Admin-permissioned ones, just regular), and try to use Enso to 'go' back and forth between them. You'll probably see the cursor stay in the first one, or possibly stay in some other window where it was originally, even as the two windows properly foreground.

Thanks again for your efforts. I hope others are able to reproduce the problem I'm seeing and that it's not terribly difficult to fix.

[GChristensen]

Can't reproduce, though added a couple of quick fixes. It may just not show, if so, please type to this window to check if focus moved there.

[tgice]

Man that's fast service! Sorry you couldn't reproduce it though.

That is how I was checking if focus was assigned properly, if I understand you correctly, I'd try typing in the window. E.g., it just happened to me again (on the version 0.1.10 one I'm running right now). My cursor was focused in this github window, typing this comment (meta, I know), and I did "go [cmd window title]" and the proper window popped into foreground (partially over my Firefox window), but the cursor stayed in this field.

Also, you said you made some fixes -- where should I go to try picking them up?

What's the best way for me to tell what version I'm running in Windows based on what I've downloaded? I see if I right click the systray icon and do about, I get a popup that mentioned 'rev 145' and copyright notices, but the download was labeled version 0.1.10, and the changelogs seem to only mention dates.

Just want to make sure I'm running your latest code and not talking about some earlier version.

Thanks again.

[GChristensen]

Also, you said you made some fixes -- where should I go to try picking them up?

The same release, I replaced it. OK, I'll add versioning information to About.

The issues with focus may be complex ones and require a long research, so there are a little hope for a fix, because I suppose there are some special local conditions take place...

On Thu, Sep 6, 2018 at 9:02 PM tgice notifications@github.com wrote:

Man that's fast service! Sorry you couldn't reproduce it though.

That is how I was checking if focus was assigned properly, if I understand you correctly, I'd try typing in the window. E.g., it just happened to me again (on the version 0.1.10 one I'm running right now). My cursor was focused in this github window, typing this comment (meta, I know), and I did "go [cmd window title]" and the proper window popped into foreground (partially over my Firefox window), but the cursor stayed in this field.

Also, you said you made some fixes -- where should I go to try picking them up?

What's the best way for me to tell what version I'm running in Windows based on what I've downloaded? I see if I right click the systray icon and do about, I get a popup that mentioned 'rev 145' and copyright notices, but the download was labeled version 0.1.10, and the changelogs seem to only mention dates.

Just want to make sure I'm running your latest code and not talking about some earlier version.

Thanks again.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GChristensen/enso-portable/issues/13#issuecomment-419168785, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKZpck_RkZ9wnVbZE2_HjRvb7PE-hHmks5uYVU1gaJpZM4Ts6ML .

[tgice]

Yep, I hear you about this possibly being difficult to track down. I don't expect you to have to hassle around with this much.

I got the new version, and see the updated about box with version.

I assume you run enso-portable yourself for daily use?

Are you running Windows 10? Mine is Windows 10 Pro 64 bit Version 1803 (OS Build 17134.254)

which I think is fully up to date. I don't think I have a very unusual environment, but could be wrong. I'm on a corporate LAN, attached to an Active Directory server.

If I wanted to futz around a bit with this myself to try some experiments, what do I need to do to attempt that myself?

I see that you made changes in this file in the recent commit:

https://github.com/GChristensen/enso-portable/commit/8c771904854b52bcce949688939dab1592d349e8

Pardon my ignorance of Python, but do I just make changes directly in that file and restart Enso and the changes will be picked up, or does something need to be recompiled?

If it's not as simple as I suggest, could you point me to some resources that might explain what is needed to setup an environment to handle such changes?

Thanks.

[GChristensen]

Are you running Windows 10? Mine is Windows 10 Pro 64 bit Version 1803 (OS Build 17134.254)

Yes, the same. But installed software may be quite evil and hooky.

Pardon my ignorance of Python, but do I just make changes directly in that file and restart Enso and the changes will be picked up

Yes, that would work.

On Thu, Sep 6, 2018 at 9:34 PM tgice notifications@github.com wrote:

Yep, I hear you about this possibly being difficult to track down. I don't expect you to have to hassle around with this much.

I got the new version, and see the updated about box with version.

I assume you run enso-portable yourself for daily use?

Are you running Windows 10? Mine is Windows 10 Pro 64 bit Version 1803 (OS Build 17134.254)

which I think is fully up to date. I don't think I have a very unusual environment, but could be wrong. I'm on a corporate LAN, attached to an Active Directory server.

If I wanted to futz around a bit with this myself to try some experiments, what do I need to do to attempt that myself?

I see that you made changes in this file in the recent commit:

8c77190 https://github.com/GChristensen/enso-portable/commit/8c771904854b52bcce949688939dab1592d349e8

Pardon my ignorance of Python, but do I just make changes directly in that file and restart Enso and the changes will be picked up, or does something need to be recompiled?

If it's not as simple as I suggest, could you point me to some resources that might explain what is needed to setup an environment to handle such changes?

Thanks.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GChristensen/enso-portable/issues/13#issuecomment-419178665, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKZpdW8UaM2zjxu8-TYeW850Fk-HT_bks5uYVyngaJpZM4Ts6ML .

[tgice]

Yes, I've seen that if I put some bogus call in that relevant section of code, Enso doesn't work after a simple restart, so I can see how to make changes.

I think the only other pointer I'd need to maybe do a little bit of fiddling around with this is how do get some basic debugging/log output. I see you have some calls to logging.debug in go.py, but I'm not seeing where I'd get that output.

I've also tried launching enso w/ the debug.bat in the root folder, but that doesn't seem to output anything of interest. Is there a log file written somewhere, or am I on the right track w/ debug.bat?

[GChristensen]

debug.bat is the main tool for debugging. But Python WinApi functions just fail without notice if something is wrong with types of arguments, necessary conditions, etc. So, only trial and error is applicable with the proper attention too pywin32 docs...

On Thu, Sep 6, 2018 at 9:49 PM tgice notifications@github.com wrote:

Yes, I've seen that if I put some bogus call in that relevant section of code, Enso doesn't work after a simple restart, so I can see how to make changes.

I think the only other pointer I'd need to maybe do a little bit of fiddling around with this is how do get some basic debugging/log output. I see you have some calls to logging.debug in go.py, but I'm not seeing where I'd get that output.

I've also tried launching enso w/ the debug.bat in the root folder, but that doesn't seem to output anything of interest. Is there a log file written somewhere, or am I on the right track w/ debug.bat?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GChristensen/enso-portable/issues/13#issuecomment-419183008, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKZpdBeqxEyH8iKfDAPb4euRLgbhTtuks5uYWALgaJpZM4Ts6ML .

[GChristensen]

It seems that I reproduced it relatively reliably: it necessary to print something in a terminal window and then try to switch to another. Everything works as expected with regular windows. Since Enso has difficult relations with terminal windows, it's a hard problem to track and fix.

[GChristensen]

v1.0.11 uses SetForegroundWindow being attached to the foreground process, it seems, that this is the key condition to set focus. Although this may fail on windows intendedly locked from SetForegroundWindow (and on terminal windows). It seems, that locked windows are the cause of the lost focus and this is unavoidable.

[tgice]

Hey, just wanted to update you on some research and experimentation I did yesterday that looks fairly promising for my situation.

I first found this thread, which discusses a similar problem experienced by people in the electron project:

https://github.com/electron/electron/issues/2867

which is described by Microsoft here (you're probably aware already of this general issue, but maybe haven't seen that explanation):

https://blogs.msdn.microsoft.com/oldnewthing/20090220-00/?p=19083

and most importantly, I think it was near the end of the electron thread, I found this workaround technique implemented in this part of the github forecfocus project:

https://github.com/robinwassen/forcefocus/blob/master/src/forcefocus_win.cc

When I attempted to migrate that approach to go.py, I am having success in a couple of ways:

a) I'm getting more consistent (possibly perfect so far) switching to and from multiple cmd windows and all others I'm trying b) This workaround also seems to have the nice side effect of allow me to switch between virtual desktops (that I normally have to manually do with Ctrl+Win+Left|Right arrow). If I 'go' to a window title on the other desktop, Windows/Enso automatically switched me where it did not seem to before. c) I also determined that my problem with elevated (administrator) level windows (like Event Viewer, e.g.) was resolved by simply running Enso itself elevated.

I'll just attach my go.py file for your review, zipped. go.zip

I commented out your recent changes and replaced with the code that does seem to work for me now. Note I first attempted to do the conditional keybd_event calls as done in the forcefocus project, but I think I was seeing some trouble with that and decided to bypass it. At one point, it seemed like this workaround was holding down my alt key (simulated) and messing up my experience after doing a go call. I think that was due to the KEYEVENTF_EXTENDEDKEY constant being OR'd into the third parameter to keybd_event, though. You can see I commented those out.

Anyway, since I saw you were still working on this, I thought I'd better pass this technique along to you since it (so far!) seems to be working great for me. Who knows how long this approach might work with Microsoft, but on the current build it seems to be good.

It seems to me that the correct solution for Microsoft to implement for this is to allow a program to request (like elevated permissions, possibly) that a user authorize it to always grab focus from any application. It's naturally understandable why Windows would not normally want to let other applications do that, but if a user expressly wants that to happen, of course it should be allow to, for applications such as enso.