Enso Launcher 1.1 closes immediately

[UI-buff]

Hi, I just installed enso-open-source-1.1-x86_64.exe on a new PC, running latest version of Windows 10 Pro - 22H2 build 19045.4170. The installer seems to run well enough, but when I run Enso Open Source from the Start Menu, all I get is a "Closing Enso" popup right away.

Please advise? I'm happy to provide any log files etc. that might help, just not sure what.

(Side note: I'm no newbie to Enso - I've been using 0.6.1 for years on another PC and am happy with it)

Thanks in advance for looking into this, and for a great productivity tool!

[GChristensen]

Hi, there should be a set of config files at %USERHOME%/.enso. %USERHOME% is your Windows user profile, e.g. c:/users/<user name>/. If there is a HOME env. variable it is used instead. The path to this directory could be found on the main Enso settings page at the backup/restore section. The first thing to try is to remove or rename this directory because it may contain faulty or old config. If this does not help, please attach here the "enso.log.stdout" file found in this directory. If there is no such file, please run the "debug.bat" script from the Enso installation directory.

[UI-buff]

Hi @GChristensen, and thanks for responding! 😄

In fact, the culprit turned out to be an old .ensorc file in that same directory. Removed it, and Enso no longer insta-quits. Yay! 😃 🥳 However, I did notice that the .ensorc file does not get auto-recreated - do I need to worry about that, or is that file no longer required?

[GChristensen]

It is currently undocumented old way of configuration. It is equivalent to the ensorc.py file in the .enso directory. It is recommended to use the latter one.

[UI-buff]

Great, thanks! 🙇 Got another issue regarding adding commands pointing to control panel (.cpl) files. Can I ask it here, or where do I go? I just donated on Patreon, is it best through there, or is there a general support forum/community I'm missing?

[GChristensen]

You may ask here. Enso uses win32api.ShellExecute from pywin32 to execute control panel applets (there are many already). rundll32.exe is passed as the program and, for example, shell32.dll,Control_RunDLL firewall.cpl is passed as arguments to run the applet. Unfortunately, technically I can't accept any donations now, but thanks anyway.

[UI-buff]

Odd, Patreon seemed to accept my payment. I've sent you a DM in there, hope we can clear the donation aspect up in that thread.

As for launching control panel windows through Enso, I'm baffled by the fact that I am able to simply find .e.g mmsys.cpl and do "Learn as open" and it works with version 0.6.1, whereas the latest version does not. Simply nothing happens when I try "open mmsys" after doing the learn as open.

I've seen the info about needing to sign Python to make elevated processes work, but for one thing, it seems very elaboratae, and secondly, I don't believe it applies to this issue, as, again, it works out of the box with Enso 0.6.1?

Thanks in advance for any help. 😄

[GChristensen]

Most likely, earlier an another function was used to open subprocesses from Enso, and it was replaced to ShellExecute fix some other bugs. It seems, that ShellExecute can handle cpl applets only through rundll.exe.

mmsys is already a built-in argument of the open command called "sounds and audio devices..." Built-in control panel applets available in the enso/platform/win32/shortcuts/Shortcuts.py file at the Enso installation directory. You can edit this file to add applets that are missing from the default list by editing it, but they will disappear when the Enso will be updated.

There is no other sane way to change the open command arguments except learn as open. Currently, the only way to open control panel applets you want is to write your own command that uses os.startfile or other similar function.

[GChristensen]

Although there is probably a way. If you use a command learn as open your_applet, there will be a shortcut .enso/commands/learned/your_applet.lnk. If you replace its "Target" path to rundll32.exe shell32.dll,Control_RunDLL your_applet.cpl , it should work and survive the Enso update. Enso restart is required after the shortcut is changed.

[UI-buff]

Wow, appreciate the detailed feedback! I'll give it a try.

May I also ask, is there a good reason why windows opened with Enso's Open command so often do not get focus? I guess it would be possible for me to add something to the Python code to ensure it did?

[UI-buff]

@GChristensen Any hope of this? (fixing the new-window-not-focused issue)? If you could just point me to the specific file/script, that would be a big help - I'll try to tweak it myself.

[GChristensen]

Hi, I've somehow missed that message. I'll try to investigate.

[GChristensen]

I wasn't able to reproduce this so far. One thing to try is to replace here SW_SHOWDEFAULT to SW_SHOWNORMAL or SW_SHOW. SW_SHOWDEFAULT tells the app to open window as the application wants it. Either the applications want their windows unfocused (for example there is already a running instance), or this may be somehow related to the settings of the Windows shell. Normally, it focuses the window.

[UI-buff]

Thanks for quick response! I just tried a couple of times, and each time, first opening the Windows Calculator, then Notepad (both via Enso) leaves the focus on the Calculator. The Notepad never gets focus. This happens to me all the time with various apps, not just these two, to be clear. I'm checking your link now. 😃

[UI-buff]

@GChristensen And following up, I've now tried swapping all 3 occurrences of SW_SHOWDEFAULT in open.py with your suggestions (1 set at a time, with enso restart after each edit) - no change. Except "Windows Calculator" was suddenly listed twice as a completion choice after my first edit. Restoring the original open.py fixed that.

I'm at a loss here. But I reckon if I can work out how to add what amounts to a "go " command inside the script following every "open ", I'd be home free. It's what I often have to do manually right now. Would that be simple to do?

It seems Notepad always opens unfocused for me if I use Enso, no matter what has focus at the time. Even on a blank desktop with no other windows. If I open it via the Start Menu, it has focus as expected. Weird.

[GChristensen]

I can only suggest to run it in a clean environment, such as Windows Sandbox, or a clean Windows installation. If it works there, this must be some software conflict.

[UI-buff]

@GChristensen This is in fact a fresh Windows install on a new PC. But just to make sure, I just tried this test in a Windows Sandbox window - same result there. (Thanks for the tip, hadn't heard about this feature before) Both when starting Notepad and Task Scheduler (both are Windows builtin apps), they do not get focus after using Enso's Open command - in my regular Windows 10 Pro or the Sandbox, it makes no difference.

I'm using the following version of Enso, and installing normally (not portable): enso-open-source-1.1-x86_64.exe

Am I cursed? It wouldn't be the first time... 😆

I can only suggest to run it in a clean environment, such as Windows Sandbox, or a clean Windows installation. If it works there, this must be some software conflict.

[UI-buff]

@GChristensen And I can add to the above, the "Notepad not getting focus" does not occur when using Enso 0.6.1 on a different PC.

Could you perhaps either point me in the right direction to fixing it by adding the equivalent of an Enso "go" command to the "open" section somewhere in the code, or alternatively, perhaps there might be a bugfix you could do? Or perhaps I'm alone in having this issue?