|
Gianluca Administrator Posts: 1274
13/12/2016
|
Hi guys.
The 5.07 is finally out and it is a really powerful version.
If you are interested in the version details go here to read the changelog http://www.ugmfree.it/SyMenuDownload.aspx#changelog
Instead with this post I would like to alert you that some breaking changes have been released or are next to be released.
The first new feature concerns the new environment variable management. No more guides to insert only certain variables. Now you can add whatever variable you like, even newly created ones. I advise you to read carefully the manual (http://www.ugmfree.it/SyMenuManual.aspx#SyProgramAdvancedEnvironmentVariables) where I hope the topic can be clarified better. It's a completely new approach so if anyone has suggestions or issues to report we can open a dedicated thread on this.
Another new feature is the resolution for relative paths. Well I admit that the previous solution was a bit weird: the relative path resolution started from the SyMenu root folder while the most natural location was from the root application path. The new behavior is exactly this last one so if anyone used the relative paths resolution, well you have to change your setting. Sorry but I release the beta version exactly to allow you to test this new behavior. Generally SyMenu hates the breaking changes but this time I was forced to introduce it.
The last point is related to the SyMenu command shell. Since it's about to die please test your programs using the new setting because at some point I will remove the option to use the command shell in favor to the Windows'.
That's all.
In the next version I'll focus my attention on increasing the performances during the SPS program definition deploy that today is really painful.
Gianluca
|
|
|
link
|
|
Glenn Posts: 99
23/12/2016
|
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?
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
23/12/2016
|
Hi Glenn.
I'm very sorry that the last change has broken all your scripts. I expected something wrong anyway because the paradigm change was really complex.
The intention was to create a simplified system to set the environment variables. The result was great, aside for the working directory management that is bugged.
This is how the programs should work.
The default working directory must be the executable folder one. If you activate the Advanced tab (near the Gesture) and specify a different working dir, this last value is taken and override the default one.
If you have no executable file but command file, like a batch one, the working dir remains the SyMenu root dir. This last behavior is subjected to change if not suitable.
The Working Directory doesn't work as an environment variable (I didn't even know that such an environment variable exists...) but works and can be set with its specific field.
The bottom multi line textbox (Environment Variables) is for changing and setting system and custom environment variables.
You can use these custom environment variables even in the Working Directory fields.
Now the 5.07 version is bugged on the working directory part, but since someone reported to me early, I have a final version almost ready to release.
Anyway since your situation is quite critical, I decided to release this version as a beta one right now.
Test it and if you find something that still doesn't work, let me know ASAP because the final version will be released soon.
This is the link to download the fixed version. Just unpack the zip and replace your SyMenu.exe file with this one.
Link removed. See messages below for the new beta version link.
And please report me any strangeness.
Gian
edited by Gianluca on 27/12/2016
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
26/12/2016
|
Hi Gian,
I have the same problem with the DOS scripts but the beta version fix the problem (well I really afraid of loosing or remake all the batch).
Thank you very much for you reactivity for resolved the issue.
I find other two more ¿related? problems:
1) "SyMenuRun32or64.exe" Autorun 32 or 64 bit version of app don't work. It gives "File Not found" message.
2) It's not possible launch VBScripts as SyMenu item "Not valid application ...." message.
Surely you need beta testers ¿Is There Anybody Out There? (some Pink Floyd reminiscences) 
!Merry Christmas and Happy New Year for all the SyMenu community¡
edited by VVV_Easy_Symenu on 26/12/2016
|
|
|
link
|
|
Glenn Posts: 99
27/12/2016
|
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?
|
|
|
link
|
|
Glenn Posts: 99
27/12/2016
|
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.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
27/12/2016
|
@VVV_Easy_Symenu
What you reported about the VBScript is similar to another report regardind the AutoIt au files. I will try to solve them all before the next release.
@Glenn
I tried to find this %WORKING DIRECTORY% instruction in the SyMenu source code but I found nothing... It means I never implemented such a management.
In this thread instead http://www.ugmfree.it/forum/messages.aspx?TopicID=371#post1026 I found that we spoke about the topic but we solved the problem putting a dot inside the working directory field instead.
This last version, the beta one, solves exactly this problem assuming the working directory is the current executable directory by default, so you don't need to put a dot anymore.
Your three points description about the new working directory behavior is misleading so I will make some examples starting from my three points based on the priority and not on the program type.
The priorities for the working directory resolution are:
- the program custom working directory if available
- the program main directory if available
- the SyMenu base dir
Examples.
Add a program item (not Windows Command but program).
Check the flag Output command
Put cmd.exe in the path folder
Execute
Have you got a program custom working directory available? No
Have you got a program main directory available? No, this is a convention I introduced because the right folder for cmd.exe should be C:\Windows\System32. But even Microsoft decides to start the cmd.exe in a different folder, in Windows 10 for example from %UserProfile%, so in SyMenu cmd.exe doesn't have a main directory.
Ok so we arrived at the catch all third point so cmd.exe will be executed from the SyMenu base dir.
Now check the Enable advanced parameters checkbox.
Write C:\ on the Working Directory field
Execute
Have you got a program custom working directory available? Yes it's C:\ so the cmd.exe will be opened on C:\ folder
Now create a batch file in whatever folder and write a simple dir command inside.
Link it to SyMenu creating another program item
Check the flag Output command
Execute
Have you got a program custom working directory available? No
Have you got a program main directory available? Yes a batch file is a real file existing in a real folder so the main directory will be the folder in which you put the batch file.
Now try to check the Enable advanced parameter
Write C:\ on the Working Directory field
Execute
Have you got a program custom working directory available? Yes it's C:\ so the batch file will be executed on the C:\ folder
The batch case is identical to any UI program case.
I hope this finally help to clarify the program otherwise please ask me again.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
27/12/2016
|
And this is the fixed version for the VVV_Easy_Symenu bug report.
http://www.ugmfree.it/public/SyMenuBeta/SyMenu.5.07.6205.beta.zip
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
28/12/2016
|
Hi Gian,
The problem with "launching VBScripts as SyMenu item "Not valid application ...." message" IS FIXED in the new SyMenu.5.07.6205.beta.zip.... you are fast!
The problem with: "SyMenuRun32or64.exe" Autorun 32 or 64 bit version of app don't work. It gives "File Not found" message in NOT fixed
(BTW: Perhaps it the moment for think some build solution in SyMenu for the large number of apps with two flavours: x86 and x64 ¿forked items?)
I have search in the AutoHotKey script code and I see that it's the script which gives the "File Not found" because:
(SyMenu Path SPSSuite = C:\Users\Public\Portables\!SyMenu\ProgramFiles\SPSSuite\SyMenuSuite)
(SyMenuRun32or64.exe Path = C:\Users\Public\Portables\!Macros)
Item call parameter = ".\ProgramFiles\SPSSuite\SyMenuSuite\7-Zip_(x86)_sps\7zFM.exe"
Symenu path passed (ERROR) = "C:\Users\Public\Portables\!Macros\ProgramFiles\SPSSuite\SyMenuSuite\7-Zip_(x86)_sps\7zFM.exe"
EXPECTED (ancient) Path = "C:\Users\Public\Portables\!SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\ProgramFiles\SPSSuite\SyMenuSuite\7-Zip_(x86)_sps\7zFM.exe
So for the ".\" it passed the relative to the item ¿the workingdir? instead of the true ".\ProgramFiles\SPSSuite..." app path.
I hope it helps to you.
Humble, humble, humble request  : I exploit that the message is in the topic "new versions" for request (yes, I know, I'm a little bit bore  ) the msi Packed Format option. I have been waiting several app of this type for to pass to the SPS SyMenu. Thank you in advance.
.
edited by VVV_Easy_Symenu on 28/12/2016
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
30/12/2016
|
As you announced SyMenu works with the priority (I add some commentaries for prepare de question):
- 1) the program custom working directory if available (if the user set in Item Advanced option)
2) the program main directory if available (For a SyMenu Program item is always available ¿Isn't it?)
3) the SyMenu base dir (¿are there any possibility of arrive a this option?¿how I can know this dir?)
So, in the SyMenuRun32or64 case and with the working dir empty, it resolves ".\" in parameters as the SyMenuRun32or64.exe working dir.
I have tried to adapt the SyMenuRun32or64 to the new situation but I only see two possible solutions:
- 1) Write in the "Working Directory" the SPS App path in "hard" code, so I lost the portability.
- 2) "Cheat" SyMenu saving "SyMenuRun32or64.exe" in the SyMenu folder, (so it returns to me ".\"="C:\Users\Public\Portables\!SyMenu"). But this is not very smart and it is not valid for all.
Of my experience in the plugin "SyMenu Published App Track" I can remember that there is not a environment variable of SyMenu dir path (perhaps may be a good occasion to add one in the SyMenu environment like %SYMENUPATH%)
So, ¿Is it possible to "force" SyMenu to arrive to the three option (the SyMenu base dir as ".\") only in the parameters?
BTW: About create a build in solution for the apps with two flavours: x86 and x64 (or even with Administrator or not Administrator rights, demanded in other topics) I could propose you create a new item "SyProgramsForked" that allows to run one or other "SyPrograms item" or directly one or other applications switch by the environment (X64, X86, elevate, etc). Even it may have properties as visible or not visible switch by the environment.
.
edited by VVV_Easy_Symenu on 30/12/2016
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
31/12/2016
|
Perhaps the good question resume of all the problem is:
¿How can I manage the SyMenu item for pass in the parameters a relative path pointing to a SyMenu portable dir (not an absolute or system dir) but not the working app dir to preserve the portability?
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
03/01/2017
|
Unfortunately Jess, the former SyMenuRun32or64.exe author is no more among us... well nothing too sad... it's now a Linux user :-)
In my opinion the problem with his script resides in these lines:
; Get the parameters
x86 = %Drv%%1%
x64 = %Drv%%2%
In my opinion the code should be written this way:
; Get the parameters
;x86 = %Drv%%1%
;x64 = %Drv%%2%
x86 = %1%
x64 = %2%
Can you try it? If it works can you share the new exe in the forum please?
Thanks.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
04/01/2017
|
Two alerts about http://www.ugmfree.it/public/SyMenuBeta/SyMenu.5.07.6205.beta.zip: (well, it's a beta and perhaps is solved yet but if nobody tells you ...)
1) Al the start, it shows always a tray tooltip of alert "Application definitions are outdated ...Nirsoft, Sysinternal" even if you have got the apps just before close in the same day. It's not translated too. I suppose that it's a new feature, but I don't find a option to disable it.
2) I see that the in the _Cache folder now the *.sps files are compresed in one zip file. ¿Is it a new feature consolidate? I ask this because the "SyMenu Published App Track" needs this sps files and I must prepare it.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
04/01/2017
|
1) Yes it's a new feature, there is no option to disable it and the message will be translated in the final version.
The alert is the first step to automatically update the SPS definitions. When this feature is ready, I'll create an option to disable the check or maybe not because it's not an online check but only a date check.
I know the bug. It's due to the year changes but it'll be solved in the final version.
2) I'm still experimenting with the compressed SPS file but I'm almost sure to introduce it in the final version. The definitions update becomes incredibly fast with the zipped SPS because SyMenu doesn't need to write hundred of files inside the _Cache folder but a single file. If you need help to align the SyMenu Published App Track let me know.
The new version should be released within this week.
|
|
|
link
|