|
Glenn Posts: 99
19/01/2016
|
OK, the manual has a section on Multi-execution:
Multi Execution SyMenu allows more than one running instance from different execution paths.
In that way you can use SyMenu from different portable drives at the same time.
Overlay unit letter on task icon (see Advanced menu - Options - Startup tab), different fixed colors and different hot keys show up so SyMenu can help you manage a multi session SyMenu system.
When SyMenu is executed from the same path of an already running instances, it doesn't execute but it makes that previous instance popup its menu.
Is/could there be a way to allow multi-execution from the same path, getting multiple independent instances? No need for the "previous instance popup its menu" feature in that case.
Why?
Using environment variables, I've been able to customize one SyMenu installation on a read-only, shared, "program" Dropbox folder to work for different projects, with different data in different project-specific Dropbox folders, but the same menu/program needs. And my users will have no problem... they work on one project at a time. So I'm the only one with the problem: I can't keep multiple instances loaded to be quickly responsive to requests for help from different projects.
I'm hoping that all the configuration boxes that supply names to the menu entries will be customizable via environment variable or SyMenu variables in some future release, as well as the "Tooltip text on taskbar icon", to go along with the other customizations I could do via environment variables.
edited by Glenn on 19/01/2016
edited by Glenn on 19/01/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
19/01/2016
|
SyMenu doesn't allow more than one instance from a single executable file because of the concurrency in write operation and because of it works with an in-memory image, so a write operation in one instance doesn't affect the other creating confusion and possible bug.
I know that you are working in a read only environment that doesn't involve any writing. Consider that this scenario wasn't expected at SyMenu birth so we are adapting the program slowly.
My proposal: I could implement a new command line -mi (multi instance) that avoids the popup to show and that make SyMenu starts another instance.
Well if you like the idea tell me immediately so I will be able to insert the new feature in the new version.
|
|
|
link
|
|
Glenn Posts: 99
22/01/2016
|
Yes, that would be a fine technique for my particular use case. -mi shouldn't directly affect the READONLY-ness, but would only be useful in the situation where all but at most one instance is READONLY.
|
|
|
link
|
|
Glenn Posts: 99
22/01/2016
|
In fact, if you wanted to restrict -mi to working only in the case where the directory can be detected as readonly, plus the case where READONLY exists, plus the case where READONLY.computername exists and the computer passing the -mi option matches READONLY.computername, all those restrictions would be fine by me, and would give assurance that the SyMenu data structures would not get messed up because of the -mi switch being present.
Well, actually it wouldn't... because the 10 copies on _computername_ would all be non-readonly in the last case. Maybe -mi should imply READONLY, in spite of a matching READONLY.computername... that way, only one instance on the machine (the first started, without -mi) would be able to make edits. Those edits, of course, would not be seen by the other instances until they were restarted. Yes, this sounds simpler to implement, and has better guarantees than my first paragraph of a few moments ago.
edited by Glenn on 22/01/2016
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
23/01/2016
|
The -mi command doesn't affect the SyMenu readonly status.
To avoid any risk my advise is to use the -mi argument only in a read only context, but the decision is up to you.
I think that the users that are able to use a command line argument know what they are doing.
|
|
|
link
|
|
Glenn Posts: 99
24/01/2016
|
I can work with -mi whether or not it implies READONLY status.
|
|
|
link
|