I've made a custom toolbar with custom tools (run from a .bat file) which I'd like other people to use (assuming they are running the same version of UEdit). I want to put the .bat file and the custom icon .bmp files into %APPDATA%\IDMComp\UltraEdit, then in the advanced tool configuration use this path, with the environment variable (so everyone can just put it in that directory and the tools will just work without having to modify ini files or anything).

However I can't get the "Working Directory" or the "Toolbar bitmap/icon (file path)" fields to recognize the environment variable %APPDATA%. I saw in the help that you can use "%Env:" to specify an environment variable but I can't get that to work in those fields.

Any idea if/how I can achieve this?

You made a syntax error.
Try this, exactly as shown (small/big letters) as command string as an example:
and it will list your application data directory.

rds Bego

Hmm, I did try %Env that way but it wouldn't work in those two fields (I just had %APPDATA% in the screenshot to show what I was trying to achieve).

I'll try it in the command field as you suggest. I assume it's delimited when it reaches a "\" (so you can append more to the path)

Yes. Env does ONLY work in command string. :-/ I agree it wold be nice in those 2 other fields ...
Online help says:
rds Bego

I have not tested it but I think you can write in the command line:

"%APPDATA%\IDMComp\UltraEdit\mycommands.bat" parameter %sel%

and let the working directory blank. I think, this works because Windows will expand the environment variable of the command, but I'm not sure. If you need to specify a working directory different to the directory of the batch file and the working directory depends on an environment variable, set it in the batch file itself.

But the working directory path and the full filename of the bitmap/icon cannot contain environment variables. UltraEdit (v14.00a and lower) do not expand them.

Has IDM ever looked at resolving this issue?

As it would certainly aid in sharing config's between systems.

I just don't like the extra noise being caught in the output window, because I have to add the working directory to the command line.

Seems like it should be a simple fix, since the code is probably largely already written.

So getting %Env: working would be nice...actually it would be nicer to just use straight environment variables.

Nologic wrote:Has IDM ever looked at resolving this issue?

The answer on this questions is NO. The first question should be:

Has anybody ever requested an enhancement for using environment variables in working directory and bitmap/icon field?

The answer on this question is most likely also NO.

In my point of view the support for environment variables for working directory is not really needed. The working directory can be blank to use the working directory of UltraEdit if it is not important which directory is the working directory, or %p or %rp is used for the working directory. If it is for some reason absolutely necessary to set the working directory depending on an environment variable, it is quite easy to use a batch file with the commands
Command dir must be replaced by real tool command. %* passes simply all parameters to the tool passed from UltraEdit to the batch file.

Bitmap or ICO files for shared tools can be also stored in a directory which exists on all computers and does not depend on environment variables, paths of the operating system, language of the operating system or user account. That makes it also easier administrating the shared programs and files.

In my company I'm responsible for some tools including UltraEdit and yes, UE is installed with additional tools by default with their own ICO files. As we use in our company English and German Windows XP x86, English Windows 7 x86 and Windows 7 x64 (and former also Windows 98, NT4 and 2000), I started from beginning installing the shared tools and the additional files like the ICO files of the user tools into directory C:\Programs. So it was no problem that the default program files directory is C:\Program Files on English Windows XP and Windows 7 x86, C:\Programme on German Windows XP, C:\Program Files (x86) for 32-bit applications on Windows 7 x64 and C:\Program Files for 64-bit applications on Windows 7 x64. And with installing the tools into subdirectories of C:\Programs the problems caused by the standard security permissions of Windows are avoided too. Further with making shared files and tools independent of user account, multiple users on same computer can use these tools without the need to install the files and tools separately for every user.

Of course the user configuration files for the shared tools are stored in the application data directories of the tools to support multi-user environments, but not the program files of the shared tools and the additionally installed shared files which are installed always into a subdirectory of C:\Programs.

Thanks as always Mofi for the in depth reply.

What you purpose is a reasonable work around...the only short coming that I can see, is a batch file isn't going to pass back to UltraEdit stdout & stderr of the tool being executed. So there won't be anything to read in the output window. I could probably write some sort of wrapper app...per tool...but while I may do that for the time being...it doesn't seem like the right path going forward.

I have sent a request for this to be looked at...hopefully something will come of it.

Again Mofi thanks for taking the time.

Nologic wrote:What you purpose is a reasonable work around...the only short coming that I can see, is a batch file isn't going to pass back to UltraEdit stdout & stderr of the tool being executed.

Well, that's not true. UltraEdit captures everything written to stdout and stderr if capturing is enabled until the called application terminates which in this case is cmd.exe interpreting the batch file. It does not matter if the batch file itself writes to stdout or stderr, or the console application(s) called by the tool.

The batch file here assumes that the called application is a console application and not a Windows application which is started by Windows as a new process.

If you are calling a Windows application which writes to stdout or stderr you need to tell the command interpreter to pause until the called Windows application terminates. This can be done with the Windows built-in command start. So instead of
the last line for a Windows application writing to stdout and stderr is
"title" is optional, but can be omitted only when the entire command line does not contain a string in double quotes. Otherwise the command start interprets the double quoted string as title parameter for itself and the call of the application does not work. Which string you use for title parameter does not matter for a Windows application.

But I do not know about many applications which are Windows applications and not console applications writing to stdout or stderr. Most Windows applications write to log files. If the output of such log files should be output to stdout so that UltraEdit can capture it to the output window, the next line after calling the Windows application with command start would be:

Ahh thanks Mofi for enlightening me.

I must say it's nice having a Guru like you around.