SyMenu Forum

Glenn

all messages by user

01/02/2016 Topic: New version bug or bugs or misunderstandings Glenn	Gianluca wrote: I can't reproduce the -sm"CTRL+F2" bug. It works for me. Can you confirm the problem with the double quotes? Took me a few days to find time to research this. Not a problem in SyMenu. It was the technique I used to launch SyMenu from Python. It seems that Python does weird things with double quotes in command lines... maybe putting in an extra \ before each ". So the bug is in Python, or my use of it, not SyMenu. Gianluca wrote: I solved the -cv casing problem. In the next version you'll got all your casing in the right place. Gianluca wrote: I never promised to remove them in READONLY mode. The important thing is that the relative forms are inaccessible. Maybe in one of the next version I'll implement this. Yes, I guess you didn't... you just replied that it was a good idea... and I assumed you were superhuman, and kept your "todo" list empty
01/02/2016 Topic: weird positioning leads to usability issue Glenn	Hah! If I'd had a "wide as screen" and "3 lines tall" tool tip like you show, I'd have never found a little piece of the menu to click on! I've rearranged my submenu so that the bottom entry has a short tooltip, and that is an OK workaround for this... it is something to watch out for, though, when designing a menu, and I didn't want to leave it unreported if you didn't know about it.
01/02/2016 Topic: a couple ideas for the future Glenn	Glad you liked my writeup. Anyway, that bit of insight into why I'm always fighting with the Windows way of doing things will help me recognize the issue more quickly, and help you understand my point of view, in trying to make SyMenu do things that Windows doesn't want to do! The whole "portable program" concept is really somewhat of a reaction to Windows integrating so many million settings into the registry, instead of .ini files... and one can see the need for doing that if one believes that there should be some many million settings to set in the first place, and if they really should apply to all programs. And some some of the millions of Windows settings should apply to all programs, but settings for individual programs are still better off in .ini files (or something equivalent), methinks. The registry is also nice in supporting concurrency of updates, which is an issue you've helped me work around with READONLY settings for my use of concurrent copies of SyMenu on Dropbox. But the registry is a total pain in the neck due to the need to "install" programs rather than just run them, and to repeatedly install of every different machine, because the settings are not portable, to be moved from one machine to another... whether via portable media, or shared online media. I'm still thinking about various possibilities for a user interface for this "visibility" option, in spare moments, but there haven't been many of them this past week.
01/02/2016 Topic: a couple ideas for the future Glenn	Oh, and regarding sandboxes. Windows implements one sandbox, but it is sort of a sledgehammer.... separate users. And so-called "fast user switching" is a way to get multiple independent desktops. I haven't played with that, mostly I've configured my machines with one user only, but when I mentioned this issue and that possible solution to a friend, he was aghast at the thought of using separate users to separate tasks because of what he claimed were onerous switching times or techniques. Another sandbox is virtualization, where you can have subsidiary OS running on the same machine. I've played with three of those: the one built in to Windows since Win7Pro but done better in Win8Pro; the Oracle one, and the VMWare one. There is a lot of setup work to get any of those to run successfully, and I didn't try using them on a separate desktop, but they do have their own environment and windows, and so they could potentially be somewhat of a solution, especially if running multiple instances on multiple desktops (if that is allowed). But this would be a sledgehammer too, requiring installing the OS multiple times as well as all the applications of interest, just to get separate "current working directory" for multiple tasks, and makes sharing of file between projects harder too, but the whole point is that sharing between projects _should_ be (somewhat) hard, because it leads to confusion when they are all dumped together. A single program sandbox (such as in a browser, or an antivirus) wouldn't solve the problem of sharing one "current working directory" context among multiple programs used for a project. I'm not familiar with the VMWare Thin App concept or the Symantec Virtual Workspace. I'll have to read the marketing blurbs on those when I get some time.
23/12/2016 Topic: New SyMenu version 5.07 Glenn	Overall, these changes sounded really nice, and I was anxious to try them out. Sadly, I didn't get time to try the Beta versions, I really wanted to... but life happens. Sadly, when I upgraded, almost all of my commands broke. I looked really hard for any relative paths, but all the paths I was specifying and/or passing in via Environment were absolute paths (calculated by a batch file that launches the SyMenu in my Dropbox environment, and the batch file is aware that other people's Dropbox paths may be different than mine). The environment variable stuff looks really nice, per command, when needed. I couldn't find the "global environment variable" section under Advanced / Options, though, that allows environment variables to be set at SyMenu startup time, that would be useful/usable by all the commands and per-command environment variable section. Of course, you hadn't documented that, and apparently didn't implement it either, so I really didn't expect to find it... but it would be very helpful, to avoid repetition in each command... and to avoid the need for a startup batch file to set such. And I wasn't using the Command Shell (had given up on it during early experimentation with SyMenu, so I'll not miss it). So, I was left with the question of why did my commands break? And what could I do to fix them. I read, and re-read, the Beta announcement, this release announcement, and the manual sections regarding environment variables and relative paths. No clue. In desperation, I started trying _every_ command that I had, and almost all of them failed in exactly the same way... a dialog would pop up saying invalid directory. I searched the forums, but there were virtually no bug reports regarding the new version... I found none mentioning invalid directory. Maybe I've missed it. Happily, there were 2 commands in my set that actually worked. Happily, when I compared all the different settings for one that worked against some that didn't, one thing became very obvious: all the commands that failed were using, as the value for Advanced, Working Directory, the value "%WORKING DIRECTORY%". This had been almost rote for me to use, such that I hardly noticed it in examining the commands initially, and it certainly raised no eyebrows nor hackles. I experimented: in one command, I replaced %WORKING DIRECTORY% with a different environment variable set by my batch file that points to the directory from which the user launches that batch file, to start the SyMenu. That command worked! Yay! I then searched the manual for a description of %WORKING DIRECTORY%, and found nothing, only generic references to working directory. I searched the Beta description again, and the release notes, and there was no mention of %WORKING DIRECTORY% being removed. Should there be? Has it been? Was I the only user of that feature, such that no one else encountered this problem?
27/12/2016 Topic: New SyMenu version 5.07 Glenn	Hi Gian, While almost all of my commands failed, I did get them all working again. But I'm not sure we are communicating about %WORKING DIRECTORY%. That is something that I had used, putting it in the "Working Directory" box in Advanced settings for almost all commands (all the ones that broke with the new version). I thought that it used to be documented, although I think that you had helped me realize the need for it in some forum discussion when I was a new user. I forget exactly how it was defined, but it helped almost all of my commands work. So you have changed something about working directory, and in particular, it seems that either you have removed %WORKING DIRECTORY% (because I can't find it in the manual now) or changed it to something that doesn't work (non-%WORKING DIRECTORY%) for almost all of my commands. AFAIK, %WORKING DIRECTORY% was never an environment variable, but something defined and usable by SyMenu? It certainly isn't in my environment. I replaced %WORKING DIRECTORY% in almost all of my commands with %gpcd% (which is an environment variable set by my batch file that starts SyMenu, which I didn't have at first, but developd later. Probably I could have switched from %WORKING DIRECTORY% to %gpcd% with the old version of SyMenu, once I developed the batch file, and then I'd have never noticed your change or elimination of %WORKING DIRECTORY%. Anyway, I got everything working within an hour of first installing the SyMenu 5.07. I still think that somewhere along the line, you should have documented the change or elimination of %WORKING DIRECTORY% so that I could have fixed things in 10 minutes, instead of an hour... So I'm not sure what really happened to %WORKING DIRECTORY%, nor did I fully understand the description of what you changed, such that up to 3 different working directories could be used? You describe it as: Breaking change - the program arguments with relative paths now are solved in these ways (ordered by priority): - from the program custom working directory if available - from the program main directory if available - from the SyMenu base dir But I'm not sure when or where or how SyMenu can guess which of these three to use for relative path resolution? Not from reading this, and not from reading the manual. And I'm not sure what you consider to have been broken, that VVV_Easy_Symenu things you have now fixed. Your description in your response to me is better. Maybe this rewording, if you agree that it is accurate, if I understand it better now, would be clearer to put in the documentation: The working directory (the current directory at the time a SyMenu command is started) will be set to one of three value, according to the following rules: 1. If the command is an external program to be launched, the working directory will be, by default, the directory in which that program is stored. 2. If the default working directory from rule 1 is unsatisfactory, you can go into the Advanced settings, and place a different value for the working directory in the Working Directory box, and that will always be used if it is specified. 3. If the command is not an external program to be launched, the working directory will be the SyMenu directory. I don't know if my description of the third option is correct. When I launch a .bat file, I specify it as a Program, and it has a path, and it has Advanced settings, and it has a Working Directory box, and I set the Working Directory just like I do for external programs, to %gpcd% (formerly to %WORKING DIRECTORY%). So I see a .bat file as a special case of an external program to be launched, it has its own path (which could be used as a default in step 1) and has an Advanced settings with a Working Directory box where I can choose step 2. I'm not sure what sort of commands wouldn't have 1 & 2, that would need a Working Directory value. Can you give a specific example?
27/12/2016 Topic: New SyMenu version 5.07 Glenn	Pondering more, I notice that my description of the 3 options is not in "priority" order... but your wording about "priority" order, is what threw me off from really understanding it on the first reading. "priority" implies (to me, maybe incorrectly) that there is some dynamic choosing going on my SyMenu; really the decision-making is all up to the user, with 3 ways to specify it. For the class of operations that have an Advanced button and Working directory box in the settings, there is a default, and an override; only of those will be used, depending on whether the Working directory is specified or not. The third technique will never apply for this case. For the class of operations that do not have an a Working directry box... I'm really not sure whether they need an implicit working directory, or if there is a program launched. Examples of such operations that actually use a Working directory but don't have a way to specify one would help me understand this better. But for these operations, there is no way to specify a Working directory, and I'm not sure they need an implicit one either, yet.
25/12/2017 Topic: The Process object must have the UseShellExecute.. Glenn	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.
25/12/2017 Topic: The Process object must have the UseShellExecute.. Glenn	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.
17/04/2020 Topic: .NET unhandled exception Glenn	SyMenu has been working great for me for years, from a Dropbox folder shared with others. So I haven't been here for a while. But today, I have a problem, that started a couple weeks ago, maybe after a Windows 10 update, and wasn't fixed by the one I got Tuesday night, so I figured I better report it here (details below, from the error dialog). So when I first encountered it, I would start SyMenu from a Dropbox folder with read-only access, the icon would appear (as usual), and I would click it to get the menu, and this error dialog would appear (which wasn't as usual). If I select continue, the SyMenu icon sticks around, but clicking it produces the dialog again (tried several times). So then Itried Quit button, and the SyMenu icon goes away. So then I start SyMenu again, and can repeat the whole process. So then, the first time this happened, I then went off to the Dropbox folder with read-write access to SyMenu, which worked fine. Leaving it running, I then went back to the read-only copy, and it worked fine too. I checked with one of my users (who only uses read-only access), and it is working fine for him, but he is using Windows 10 Insider (I think). And other users haven't reported this issue. Now today, I needed to run this same thing again, and went to the read-only copy, and got the same error dialogs and behavior. I'm about to try the writable copy again. So I start it up, the icon appears, I click it the menu opens, I choose one of the menu items, the command runs successfully, and for variety, and debugging, I close the read-write SyMenu. Returning to the read-only SyMenu, without the read-write copy running, I get the same error dialogs and behaviors as described above. Starting the read-write SyMenu, I go into the configuration menu to note the version of SyMenu: v6.01.6493. I've noticed upgrades from time to time, and checking the download page here, I see I'm a few versions back. So maybe this will be fixed by ugrading SyMenu, or maybe not. With the read-write SyMenu running, I start the read-only SyMenu again. This time it still doesn't work, but behaves as described above. Trying the update, I get a SyMenu dialog: Error in update process. Please manually download and install SyMenu. It's been so long, I'll have to figure out how again! I wonder if I turned off automatic updates, or why they haven't been happening? Ah yes, found the unchecked Check Version box. Hmm. Lots of changes since my current version. These look like they might be incompatible... Fix - A relative working directory (.\) is lo longer resolved from the SyMenu root path but starting from the current item root path The SyMenu CMD shell is finally removed Upgrading manually is not covered in the manual, even though the above dialog suggests it. How does one upgrade manually, wihen they already have a configuration they want to use? So the manual does tell where the configuration data is kept; I unpacked the software as directed for a new installation, copy the whole Config folder into the new empty Config folder, and gave it a try, but it was in a different folder than where my commands were, but at least the menus showed up. So then I copied the whole new software+old Config folder back over to the "old installation" area, and it seems to run there, executing at least some of the commands. It would be helpful to mention how to do this in the manual. So I don't really expect support for old versions of the software, even though I provided as much diagnostic information as I could. I decided to post it all, though, in case someone else experiences something similar. Microsoft .NET Framework Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Object reference not set to an instance of an object. Details Continue Quit See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************ Exception Text ********** System.NullReferenceException: Object reference not set to an instance of an object. at SyMenu.FormTaskBar.ContextMainMenuShow(ShowMenuEventArgs e) at SyMenu.FormTaskBar.notifyIcon1_MouseUp(Object sender, MouseEventArgs e) at System.Windows.Forms.NotifyIcon.OnMouseUp(MouseEventArgs e) at System.Windows.Forms.NotifyIcon.WmMouseUp(Message& m, MouseButtons button) at System.Windows.Forms.NotifyIcon.WndProc(Message& msg) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ********** Loaded Assemblies ********** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.8.4121.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- SyMenu Assembly Version: 6.1.6493.31478 Win32 Version: 6.1.6493.31478 CodeBase: file:///D:/my/dropbox/0-gp/SyMenu/SyMenu.exe ---------------------------------------- eFJbeTVfWuEFvWfnBtBecgDqjxNV Assembly Version: 0.0.0.0 Win32 Version: 6.1.6493.31478 CodeBase: file:///D:/my/dropbox/0-gp/SyMenu/SyMenu.exe ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.8.4121.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.8.4001.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.8.3752.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.8.3752.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.8.4121.0 built by: NET48REL1LAST_C CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.8.3752.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Xml.XLinq Assembly Version: 1.0.2319.19042 Win32 Version: 1.0.2319.19042 CodeBase: file:///D:/my/dropbox/0-gp/SyMenu/System.Xml.XLinq.DLL ---------------------------------------- System.Query Assembly Version: 1.0.2319.19041 Win32 Version: 1.0.2319.19041 CodeBase: file:///D:/my/dropbox/0-gp/SyMenu/System.Query.DLL ---------------------------------------- Ionic.Zip.Reduced Assembly Version: 1.9.1.8 Win32 Version: 1.9.1.8 CodeBase: file:///D:/my/dropbox/0-gp/SyMenu/Ionic.Zip.Reduced.DLL ---------------------------------------- System.Management Assembly Version: 4.0.0.0 Win32 Version: 4.8.3752.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Management/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Management.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 4.0.0.0 Win32 Version: 4.8.3752.0 built by: NET48REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- ********** JIT Debugging ************ To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box.
17/04/2020 Topic: .NET unhandled exception Glenn	Indeed, I was surprised at how old; for a while (as you likely remember) I was quite actively developing my use of SyMenu, and actively requesting features and tweaks, and you were very accommodating in understanding the needs and implementing the features to accommodate use on Dropbox. But after that time, it has been working so well, I sort of ignored it, and was developing other aspects of my system. > It's true, in the manual there is no clue regarding the manual installation. It's because the manual installation is so easy... unzip the package and overwrite everything in you working folder. This way all the configurations and programs will be preserved. I suppose it is easy... if you happen to have learned and remember the details of the SyMenu file structure. But given that it is so easy, it wouldn't take a large amount of space in the manual to mention it, allowing people that haven't learned the details, or have forgotten them in a span of time, to be able to quickly and with certainty learn or be reminded of those details. As I mentioned, I found mention of the Config folder in another section of the manual. I missed out on any significance of Program Files. I see in my saved copy of old SyMenu that my Program Files in my shared area where this happened, has nothing in Program Files. So I guess I can remove the contents of Program Files from the new SyMenu installation (to save space). Well, looking inside, there is nothing there but a folder structure devoid of files! So I guess there is not much space to save! I described what I actually did: installed SyMenu elsewhere, copied by Config folder content to the new Config folder, and then copied everything back on top of my shared area. So maybe I have some old files left over? So far, they aren't causing problems, but are probably consuming space. So now I've deleted the whole shared SyMenu folder, and copied again from my new install that has only the Config folder added. Since my Program Files was basically empty, that should suffice. > I haven't understand well the configuration of your read only Dropbox but it seems that you forced the read only status on Dropbox itself. This way all the people using SyMenu are not in a real read only state, but they can change whatever they wont and then Dropbox refuses to synchronize it. Is it true? If it is the real scenario I advise you to help the users and their local SyMenu installations to understand that they are working in read only mode. Yes. Fiddling with the READONLY file works, but is annoying. I have READONLY turned on. But when start my read-write copy, I turn on READONLY.mycomputer temporarily while starting SyMenu. So my users don't understand SyMenu well enough to reconfigure it, and I am the only one that configures it, and it is seldom I need to do anything for that subsystem these days. It is working pretty well. And when a bug is found, or an enhancement needs to be made, it is very seldom in SyMenu configuration. I think I'm remembering now why I turned off the updates 3 years or so ago: the SPS packages changed far more frequently than SyMenu, and I'm not using any of them, but am using SyMenu with my own programming. So I guess if there was a way to turn off updates for the SPS packages separately from SyMenu itself, I might be more inclined to keep SyMenu itself up-to-date. But it became annoying to get update notices for stuff I don't use. Maybe I should put something in my calendar to update SyMenu once a year or so... > IMHO it's not a problem related to SyMenu but it's tied with external elements. If I well understand the problem, it affects your read only copy and not the other users copies. Apparently so, as I got no reports from users, and the one I asked had no problem. I use the same user to run the read-only and read-write versions. The lengthy stack trace that was included in the dialog seems to indicate that .NET was involved in the issue. That likely has changed signfiicantly in the 3 years since I updated SyMenu. You may well have adjusted to minor, probably planned and announced, possibly incompatible changes over time. I do not use or track changes in .NET, but I see it get updated with Windows Update from time to time. So the old SyMenu might have been using a now-deprecated .NET feature, or might have had a latent bug that some fix to .NET caused you to fix... but that I didn't get. The new version is working for me in both read-only and read-write access. So far. I'll come back if you have questions or further suggestions.
17/04/2020 Topic: .NET unhandled exception Glenn	So I'm looking over the new command line parameters. So if I had two installations of SyMenu... one on Dropbox, shared, readonly, with READONLY in the root directory, and everyone used that, everyone would be readonly. I would be able to use it too, even with read-write access to the directory, and it would readonly to me. But then if my second copy did not have READONLY in the root directory, and used -fc to point to the other installation, I could run that copy when I wanted to have read-write access? Would that work? Of course, to see the changes, the READONLY copies would have to be restarted.
18/07/2020 Topic: 2 minute delay after closing configuration dialog Glenn	First, a boring history story/paragraph to provide context: So, although a long-time user of SyMenu on shared Dropbox folders supporting a variety of projects, I had used other tools on my primary computer. The "Free Launch Toolbar" worked for a while, but seemed to be dependent on file structures set up and used by IE, which got deprecated. And then I got a 4K monitor instead of two portrait monitors. But I had grown used to having my task bar (containing my Free Launch Toolbar) on the left edge of the right-hand portrait monitor.... in the middle of the work area. I saw no reason I should be forced to mouse all the way to the left or right edge of the 4K monitor to find my task bar, so I looked for a different solution, and found Winstep Nexus. It has some interesting features... in addition to allowing a group of icons representing folders in a toolbar that can be positioned anywhere on the screen, it also allows the icons from the system tray to be included in the toolbar... these capabilities pretty well emulated my prior use of a taskbar in the middle of my work area, after a bit of configuration. Recently, however, Nexus has not always been allowing selections to be made from the folder expansions, and when I set up a new machine this month, that bug occurred much more frequently, and the workarounds I and their support person came up with are not quickly effective, and after using them Nexus will frequently crash, and restarting it often takes several retries. After too many issues and crashes to bear, I decided to set up the basic folder configurations using trusty SyMenu. The attached picture shows the menu I came up with, pretty simple, 6 folders (the bottom one is new and will point to the Dropbox projects when I complete it, so 5 presently useful folders) in the middle, a quick access to CMD prompt, and shutdown button (which is an AHK script that knows how to shut down active processes in a good order before invoking Windows Shutdown which sometimes only does a logoff if the shutdown takes too long!). During the setup process, I noticed that after doing "Save and Exit" from the configuration dialog, that the floating "start" icon would go away for a while, and the icon in the system tray would be non-responsive for a while. After getting the upgrade to 6.11, I decided to see if that still occurred, and to time it... roughly, just by using my digital watch's "minute hand"... if more accurate timings are needed, I could use the stopwatch on my phone. I was extremely surprised to discovered that the whole process actually took over 2 minutes! The floating icon was gone for over one of those minutes, and after it appeared, it didn't respond to hover (as configured) and clicking it produced a blgger black background and a "busy wait" circle cursor from Windows. I don't recall this happening in my other configurations on Dropbox, and they are far more complex than this one. Once the SyMenu icons decide to respond, then I get the usual rapid response I've come to expect from the menus. Any clues as to why there is a two-minute delay? Nexus has a bunch of "fluffware" features that I didn't use much, but didn't figure out how to eliminate them from the task bar either. But it has a couple features that I really like, and that might be considered for adding to SyMenu. 1. The toolbar concept. This is sort of like SyMenu's floating Start icon, except the main menu is pre-expanded showing icons only. Now Nexus allows the toolbar to be either horizontally or vertically oriented containing those icons, but then when clicked, they open to a vertically oriented submenu. I only ever used the vertically oriented toolbar in the middle of the 4K screen. The toolbar uses icons that are roughly the same size as the Windows taskbar's "Large" icons, whereas I actually use "small icons" in the real Windows taskbar (which is still inconveniently position there on the far left edge of the window, for use when one of the many windows on my desktop gets completely hidden and I need to click it to the front). 2. The system tray icons being included in the toolbar was handy, as they were in a more visible location. I don't know how they do that, but the toolbar reflects the icons in the system tray dynamically, as the icons would change to reflect the state changes for whatever program they were for. And they were clickable too, but the clicks apparently got sent to the "real taskbar" icon, and any menus that opened as a result of clicks appeared there. On the other hand, tooltips generated by hovering over the icons are visible close to the Nexus toolbar copy of the icon, which was also quite convenient. My current plan is to run both Nexus and Symenu on this machine, and get the nice toolbar feature of Nexus when it works, and when it doesn't, to have the expected-to-be-more-reliable SyMenu available for use, so I can get something done beyond fighting with Nexus.
20/07/2020 Topic: 2 minute delay after closing configuration dialog Glenn	Well, what you are suggesting is effectively what I did to create the shown menu and timings. I copied a configuration from my master Dropbox SyMenu configuration, to my local disk (actually, an NMVe flash drive), deleted all the commands existing commands, and added in the 6 folders shown. So I did it again. Made another copy, started it up, change the "hover" message for the icon, and saved. 85 seconds before the menu (menu on hover) popped up.
17/01/2023 Topic: The Process object must have the UseShellExecute.. Glenn	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?
17/01/2023 Topic: The Process object must have the UseShellExecute.. Glenn	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.
17/01/2023 Topic: The Process object must have the UseShellExecute.. Glenn	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.
18/01/2023 Topic: The Process object must have the UseShellExecute.. Glenn	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.
18/01/2023 Topic: The Process object must have the UseShellExecute.. Glenn	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