sl23 Posts: 285 11/09/2015	sl23 Posts: 285 How does the option for advanced parameters for AppData work? Does it specify the directory the app should use instead of the system's AppData folder?
	link
Gianluca Administrator Posts: 1274 11/09/2015	Gianluca Administrator Posts: 1274 Interesting question. When you active the Enable advanced params flag and set the AppData, you are simply defining some environment variables valid for your program. Precisely before launching the program, SyMenu sets these variables with the AppData value: - applicationdata - appdata - localapplicationdata - commonapplicationdata Naturally if the environment variable doesn't exist it replaces nothing and, from the Win7 and upper OS, the only existant environment variable among the four ones should be the second: appdata. Then SyMenu launches the program. In case of the program asks to the OS where the appdata folder is the reply will be your customized one.
	link
sl23 Posts: 285 11/09/2015	sl23 Posts: 285 Please accept my apologies for lack of understanding, but does this mean I was correct? Launching an app with symenu allows apps to use a user defined appdata folder?
	link
Gianluca Administrator Posts: 1274 11/09/2015	Gianluca Administrator Posts: 1274 It depends. The reply is yes only if the launched program reads from the OS environment variable where the appdata is located. The reply is no, if the program searches for the appdata in a different way (for example calling the SHGetFolderPath Windows API).
	link
sl23 Posts: 285 11/09/2015	sl23 Posts: 285 I see, so in certain situations it can be used, that's good to know. Now, er, how is it used? Do I just tick the box or is the path necessary? If path is required, do I create my own directory structure or is it done automatically?
	link
Gianluca Administrator Posts: 1274 11/09/2015	Gianluca Administrator Posts: 1274 You have to tick the box and specify your appdata custom path otherwise the program will use the system one. Yes you have to create the custom folder before launching the program. SyMenu doesn't take charge about the creation of any folder (except for its own ones).
	link
sl23 Posts: 285 11/09/2015	sl23 Posts: 285 OK thanks Gian
	link
Glenn Posts: 99 06/10/2015	Glenn Posts: 99 Regarding environment variables, is there a way that one can set an environment variable to the same value as %WORKING DIRECTORY% which does not actually appear in the environment of launched programs? It seems that setting APPDATA to %WORKING DIRECTORY% produces an error -- I suppose that those 4 boxes are expecting actual path names, rather than environment variables that (could) expand to path names? Is there some way to specify that APPDATA gets set to the equivalent path? It would be nice to have the ability to set _any_ environment variable to _any_ value... either a path with Universal Unit Identifier expansion or expansion of other environment variables, or SyMenu variables, or both (as long as there is a syntax that allows escaping the expansions so they don't happen, in case the reference matches as desired value). edited by Glenn on 06/10/2015
	link
Gianluca Administrator Posts: 1274 13/10/2015	Gianluca Administrator Posts: 1274 Yes the environment variables are not expanded into the fields AppData, HomePath, UserProfile, ProgramFiles. I have to enable this fields too with the SyMenu envronment variable converter. Since without an example I can't help you so much, doesn't a simple . (dot) work inside the AppData field instead of the %WORKING DIRECTORY% environmente variable? Can you try that and report?
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 I never thought to put a "." in APPDATA! Sure it works. But it would be nice to be able to set any environment variable to any value, including references to other environment variables and potentially to SyMenu variables as well. Some programs define particular environment variables that they respond to, and it may be useful to be able to set them differently for different invocations of those programs from a single SyMenu instance.
	link
Gianluca Administrator Posts: 1274 17/11/2015	Gianluca Administrator Posts: 1274 You are a genius. The only sane and useful environment variable is indeed the Working directory. All the others are rarely used and difficult to manage too but if a user like you needs to use them, he needs flexibility and extensibility. So I could remove all the managed environment variables except the working directory and leave the possibility to include whatever environment variable you want with a simple multiline textbox. You'll have variable expansion, relative path resolution and whatever you already have in the working directory. What do you think?
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 Well, I think Albert E. and quite a few others are ahead of me in the genius category! Yes, the 4 you have presently may be useful in some circumstances, but it seems rare. APPDATA I needed once, and worked around it when I couldn't figure out how to put %WORKING DIRECTORY% in it, and didn't think of ".". I can think of programs (not necessarily portable ones) that use each of APPDATA, HOMEPATH, and USERPROFILE. But I have never come across a program that actually looks in PROGRAMFILES for anything... and these days, with 64/32 and "Program Files (x86)", such programs would probably be broken anyway. You have a nice "browse" button next to each of those... but it seems to select fully qualified paths, which would then need to be front-truncated and edited to make the path portable, if #: can even be used in them... a user can get the fully qualified paths from other sources, such as Windows Explorer, copy as path feature, if they are needed. A multiline textbox sounds good to me... I'm envisioning that each line could be an environment variable definition, and that expansion of %var% would happen (both environment and SyMenu, making SyMenu variables from the command line have another use?), as in: APPDATA=. MyPath=#:\over\here MyFile=.\over\%there% fonts=%windir%\fonts VERBOSE=3 SyMenu.exe -sv"there=the\hill"
	link

---