|
Glenn Posts: 99
25/12/2017
|
The following dialog now appears when I attempt to use some commands that I set up a long time ago and which worked then, but haven't used for a while. My SyMenu was not the latest, so I upgraded, and it still occcurs.
SyMenu - Error in command.
---------------------------
The Process object must have the UseShellExecute property set to false in order to use environment variables.
The message text seems to be from .Net, but I don't see that I have control via SyMenu to change the property referenced, nor do I know exactly what it means or does, not being a .Net user. Maybe I do have control. The command of interesting is a direct invocation of a .bat file. And it certainly wants to use Environment variables. Other similar batch file commands are also failing in the same way.
I did a forum search for the message text with no results, but haven't been keeping up with reading the forums like I have in the past... because I haven't had problems with SyMenu until now: it's been working great, except these 4 batch file commands, which I haven't used for a while.
Do I just need to change them to invoke CMD with the .bat as a parameter? I see I have some invoked that way, that seem to work fine.
|
|
|
link
|
|
Glenn Posts: 99
25/12/2017
|
Well, I was able to rework the .bat files to invoke CMD with "/c file.bat other parameters" and make them all work again. Maybe I missed doing those when it was first necessary, but fixed others? I can only say that the error message received from .net doesn't trigger the intuition about what is actually going wrong. Of course, I don't know what is actually going wrong, either. So I should say, it doesn't help with knowing what to change to fix it.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
27/12/2017
|
Hi Glenn,
Sincerely I don't know what the problem could be.
The UseShellExecute is set to true when you run something with different credentials (RunAs), when you execute a program in elevated mode or when you execute something different from an .exe.
But a .cmd is different from an .exe in the same way a .bat is, so I can't understand why the first works while the latter doesn't.
If you want to send me in private the two items I can test them a bit.
|
|
|
link
|
|
Glenn Posts: 99
17/01/2023
|
So I was able to trigger this error again! Using version 7.01.8127 it seems. It hasn't given me an auto-update to the latest version, yet, although it has from time to time. I see that I have 7.03.8322 as my main menu system, the version above is on a Dropbox shared drive used by a number of others besides myself.
I have a version of Python (3.7.2) installed in the same Dropbox folder as the instance of SyMenu. I place the path to that version in an environment variable, and some additional params to specify the Python script to run. Works fine. but then I want to test with a different version of Python, so I set the environment variable to this other version that is installed in drive C:\Program Files\Python311 (version 3.11.1). This triggers the error about UseShellExecute must be false.
So I would suppose that the difference is not the numerical version of Python installed in my "same directory structure", but rather in the way the versions were built and/or installed. The one in drive C was built by the Python foundation, and installed with their standard installer, but the other versionn is a portable version built by another person/group, and installed with their installer.
In both cases, SyMenu is doing the execution, the difference must be something that SyMenu (or .NET underneath, or Windows 10 underneath) is detecting as a difference between the executables. I wonder if there is a way to determine what the difference is?
I suppose I should update my Dropbox to also have the newer version of Python, built to be portable, but just pointing to the other copy for my testing seemed so much easier... until I got the UseShellExecute error.
Based on your last message some years ago regarding this error, I can confirm that both Python instances are .exe, I'm not specifying RunAs or elevated mode. So maybe there is some other trigger for UseShellExecute?
So I look at the "Properties" dialogs for the two different Pythons.
The Dropbox version has only 4 tabs, the "Program Files" version has 6! The Dropbox version has a "Customize" tab that is not in the "Program Files" version, the "Program Files" version has three other tabs: "Compatibility", "Digital Signatures", "Details". None of the boxes in the Compatibility tab are set, not even "Run the program as an administrator". The other tabs seem to be innocuous.
Comparing the General tab seemed innocuous as well.
The security tab for Dropbox listed Authenticated Users, SYSTEM, Administrators, Users.
For Program Files Python, the security tab didn't list Authenticated Users, and also listed ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES. I added Authenticated Users, but it didn't help, even after restarting SyMenu.
Do you have any other clues, as you might have gotten more knowledgable about this topic in the last 5 years?
|
|
|
link
|
|
Glenn Posts: 99
17/01/2023
|
Found this quote over at stackoverflow.... When the path contains a space or some other special (i.e. accented) characters, CreateProcess (UseShellExecute=false) seems to be using short file names ("DOS" 8.3 notation), ShellExecute (UseShellExecute=true) uses long file names. So when you use UseShellExecute=false, make sure to convert your directory and file names to 8.3 names (google ".net how to get 8.3 filename"). (Not exectly sure what Windows versions and/or file systems do it this way, tested on Windows 7, NTFS.)
Does this mean that no program installed in the standard Windows location of "Program Files*" can be started without UseShellExecute being true? Because of the space in the directory name? Unless, perhaps short names aliases exist? I think short names are an option these days, and I think when I saw the question I said "no short names", but I forget where I saw that, or if that was only on Windows <11.
|
|
|
link
|
|
Glenn Posts: 99
17/01/2023
|
Well, no, it is not just that, anyway.... I uninstalled the "official" Python 3.11.1 from my machine, and reinstalled it at c:\Python311, and still get the UseShellExecute error.
|
|
|
link
|
|
Glenn Posts: 99
18/01/2023
|
So is that message a result of SyMenu catching an exception from .NET and the message being from .NET, or is it one that SyMenu generates because of detecting inconsistencies on its own?
I found this, but I fear it leaves out a lot of environmental detail. I do wonder if somehow the "official installed" Python is somehow configured into the Windows shell with a setting that prevents it from being directly executed by .NET, even though it can be executed successfully from CMD with file redirection, environment passing, etc.
|
|
|
link
|
|
Glenn Posts: 99
18/01/2023
|
Curiously, an instance of SyMenu running outside of Dropbox can run the "official" Python installed in c:\Program Files.
So it would seem that there is something inside of SyMenu that is causing the difference... or something specific to the SyMenu command line parameters or the Item configuration.
Here is my command line, if it helps: D:\my\dropbox\0-gp\SyMenu\SyMenu.exe -mi -cvsmproj=HON87-new-font "-cvsmhk=\"- Hotkey=\"" -sm
|
|
|
link
|