|
Glenn Posts: 99
17/04/2020
|
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.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
17/04/2020
|
Dear Glenn,
You have a very old version.... SyMenu 6.01 is coming from the 2017...
From that version a lot has changed and above all the file organization has changed.
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.
But this is true only for the same program family version and you are on the older one.
So for a manual installation, you - you and not any other user because you have that version - need to delete all the files from the SyMenu root folder (carefull! Files and not folders) plus the folders x64 and x86. Now you can unzip the new package in the root.
Just to know, the sacred folders you have never to touch are: Config and ProgramFiles.
Let's analyze your issue now.
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.
How? Simply put a read only placeholder file named READONLY in the root folder (https://www.ugmfree.it/SyMenuManual.aspx#Readonly_mode). When you need to update the master copy of SyMenu or its programs, rename the file without synchronizing it in Dropbox, update what you need, then activate again the READONLY file, now synchronize. Or use the named READONLY file.
The use of READONLY file is flexible but as I assert in the manual is not a security measure. In your case it's only a way to help your users.
Ok now let's analyze your issue more precisely.
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.
In this case it could be a problem in Windows security permission. SyMenu is able to work with at least Read and Read & Execute permissions otherwise it breaks.
Or you have a problem with the user you use to work with SyMenu. Authorize it on every SyMenu folder with the right permission.
And please report your outcomes.
|
|
|
link
|
|
Glenn Posts: 99
17/04/2020
|
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.
|
|
|
link
|
|
Glenn Posts: 99
17/04/2020
|
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.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
17/04/2020
|
Glenn wrote:
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.
Your configuration is unusual but perfectly legal. Probably you installed all your programs in a different folder than ProgramFiles and SyMenu really doesn't care where you install your them because it is able to solve with relative paths every path on the same unit (your case I suppose) and with absolute paths every path on different units.
The ProgramFiles folder is a suggested location for your programs, not mandatory anyway.
Glenn wrote:
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.
Yes, in your case it is.
Glenn wrote:
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...
If you are referring to the SPS package updates, you won't have notices unless you've installed one of them. SyMenu silently update the SPS definition but never bother you about that. If you installed one of the SPS program and that one is outdated, the new definition wakes up your SyMenu that notifies you. But, again, it seems not your case.
If instead you are referring to the new SyMenu features related to the SPS, well you have to update SyMenu because SPS and the other features are strongly tied together, you can't choose what you want and what you don't. I recommend everyone to update SyMenu as soon as a new version is available.
Glenn wrote:
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.
.NET is not related to the error you got but since it's the platform on which I develop SyMenu, it simply communicates you that an error has happened.
If an old .NET framework becomes incompatible with SyMenu I will notify the user appropriately. So if you are able to execute SyMenu, don't worry about the .NET framework.
Instead if you maintain the framework updated, Windows does the work for you, you can eventually have new features in SyMenu but the program won't be broken by an old .NET version.
Glenn wrote:
The new version is working for me in both read-only and read-write access.
Since you copy all the SyMenu files back and forth you probably fixed the Windows security configuration. It's not related to the new SyMenu version in my opinion.
|
|
|
link
|