User to user discussion and support for UltraEdit, UEStudio, UltraCompare, and other IDM applications.

General and specific configuration/INI settings
12 posts Page 1 of 1
Info from Mofi: This topic was created by splitting up the posts from SSH/Telnet functionality in 12.20 -- can't find it into this and the linked thread!



Ah, yet another trap for UE being not-sufficiently-XP-aware. I didn't get that menu updated because that is *yet*another* thing that you end up needing to do as administrator. Even after all of these years, I'm surprised at how many otherwise-shaped-up applications *still* believe it is OK to store their configuration information in the install directory [or c:\windows]...

This answered a bunch of questions [more to the point, since I've now "lost" the "do you want me to update the menus" dialogue box, is there any way to get it back [or at least find out all the OTHER things besides the SSH menu that I"m now missing because I don't run as admin]? [I, too, thought I was going nuts looking for the SSH functionality. The help files talk about how to configure it, but not a hint [that I could see] about where you were supposed to find it].
bernie wrote: Ah, yet another trap for UE being not-sufficiently-XP-aware. I didn't get that menu updated because that is *yet*another* thing that you end up needing to do as administrator. Even after all of these years, I'm surprised at how many otherwise-shaped-up applications *still* believe it is OK to store their configuration information in the install directory [or c:\windows]...

Ah, yet another user which complains without reading help or the readme file. (The name of the file is README.txt and not DONTREADME.txt). Since v10.20 all new installations store all configuration files in the personal user application data directory as suggested by Microsoft. This by default hidden directory is for installations on English Windows 2000/XP:

C:\Documents and Settings\user account name\Application Data\IDMComp\UltraEdit\

or correctly %APPDATA%\IDMComp\UltraEdit\ which is working on all Windows since Windows NT4.

So there is no problem with administrator privileges. For users who updated from a pre v10.20 installation the existing configuration files are used further independent where they are stored to don't lose any user setting after upgrade.

And yes, the configuration files can be anywhere - read in help of UltraEdit the page titled INI File Selection and Advanced Settings. How often have I posted this, I cannot count it anymore. See FOR EXAMPLE How to transfer configuration settings to a new PC which files you have to move from Windows to the application data directory or any other directory you want, for example with usage of UEINIDIR.
Best regards from Austria
Sorry, Mofi, but this is bollocks.

1. A well-behaved Windows programm should just work in that regard and it should not require you to read any readme files.
2. The Windows directory should be off-limits for any application. If you want to share settings among all users, you can use the "All Users" directory under the %APPDATA%" dir.
3. UltraEdit (at least v12.20 and above) do NOT work as advertized in the help file. Just before I encountered this thread, I tried very hard to fix my installation. I, too, am not working as administrator. UltraEdit will work fine until I do become admin. It will then plant its ini file into the windows directory although there is an ini file in the admin's appdata directory. Changing back to my normal account, UltraEdit will then use the ini file in the windows directory, but won't be able to change it, of course. I had to resolve to using the UEINIDIR environment variable to make it work.
Sorry Manni, but

  1. You don't need to read the readme on first install, but you should read it always on updates. I do this always when I update a program not only for UltraEdit and it was always important for me to read it to get informed about important changes and new features. Some programs have an additional history file. If possible, I read the readme before I install a program. That's important for example on all Adobe products. I have fixed many problems with Adobe products because a user has installed the program wrong because not reading the installation steps in readme before installing it.
  2. That's what all IDM products do, except when installed on Win9x because the old Windows versions don't have an APPDATA environment variable although Win98 SE (not Win98) has also an application data directory. But the application data directory on Win9x, if it really exists, can be only found via a registry entry which can but must not be present. It's easy for new programs which do not support Win9x or NT4 to be Win2K/XP compatible.
  3. In the help it's explained in detail in which order the program name.INI file is searched: first command line parameter, second the environment variable, third the program directory, fourth %WINDIR% and last %APPDATA%\IDMComp\UltraEdit. The last one is not possible on Windows 9x as long as the user does not set APPDATA in AUTOEXEC.BAT. If not found anywhere the last one is used (APPDATA for NT4/2K/XP/2003, WINDIR for all other where environment variable APPDATA does not exist). And that's exactly what I can see. Well, I have never tried it with a restricted user mode. But I have several shortcuts with an INI file specified on the command line.
If you only copy your UltraEdit configuration files to the %APPDATA%\IDMComp\UltraEdit directory and not move it, UE will still find it first in the Windows directory and will continue to use it from that location. Please note, the search order is caused by compatibility. UltraEdit is a very old program. It exists since Windows 3.1.
Best regards from Austria
Believe me.

I have spent 30 minutes this morning to get UltraEdit working in a multi-user environment on WinXP. I have a set of ini, uek, and whatnot files in the admins appdata directory. UltraEdit doesn't give a f* and will use the Windows directory although I made sure to delete all UE files from there between runs. The *ONLY* option I was left with (because I didn't want to mess with shortcuts which won't work for double-clicks or right-clicks from explorer) was the UEINIDIR environment variable.

I could NOT get UltraEdit to use appdata/admin, no matter what the documentation says.
Mofi wrote: Ah, yet another user which complains without reading help or the readme file. (The name of the file is README.txt and not DONTREADME.txt).

What file are you referring to? I updated UE by downloading a .zip file that had exactly *ONE* file in it: "uesetup.exe"

Since v10.20 all new installations store all configuration files in the personal user application data directory as suggested by Microsoft.
...
So there is no problem with administrator privileges. For users who updated from a pre v10.20 installation the existing configuration files are used further independent where they are stored to don't lose any user setting after upgrade.

I don't think that UE asked me anything about my configuration setup when I installed the update [hard to remember now]. I believe that the only choice I was given was "what directory" and I selected the same directory I'd previously had UE installed into. It did ask me for a few "do you want me to overwrite the words file"-type dialoges, but if it warned me about the config files I'm afraid I missed it...

And yes, the configuration files can be anywhere - read in help of UltraEdit the page titled INI File Selection and Advanced Settings. How often have I posted this, I cannot count it anymore.

I see what you're saying, only I doubt seriously that the help file page on "INI file Selection and location" would be even on my top-ten list of "where to look to find ssh". And as I mentioned, I was a bit confused by the update: I fire up UE from my limited acct [from which I've used UE for a *long* time now] and I get a mysterious dialog [about updating the menu bar or some such] and then it says "failed". Other than that, UE was fine [oh, except: that I couldn't configure the SSH machinery until I had found and changed the ACLs for the UE config files in c:\windows

I see from your comment [and that I'm not the only one confused by the ACL/config problems with the upgrade] that moving from the awful world of the Win9X platforms to XP isn't such an easy thing to do (either for the application programmer or the user :)). I guess my inclination would be that when the program starts-on-XP and sees that it has win9X config files, it might consider copying them into the XP-appropriate place for the current-user, rather than just using them from where they were. Perhaps something to think about as Vista looms and it will be even MORE picky about permissions and access than XP is.
To Bernie:

Yes, the readme file is unfortunately also packed in uesetup.exe. The most important changes are shown during the installation procedure (saved in file changes.txt in the program directory after installation). Most users simply don't read it and just press OK. But the readme file can be read immediately after the installation by clicking on the appropriate shortcut in the start menu. Hm, is the readme file opened with UltraEdit or Notepad? I must confess that I always delete the shortcuts immediately after installation and use the Lister of Total Commander to read the readme before I start first time the new version. (And I always create a backup of ALL files of a program before I update I program because I'm very curious and want always know what has been changed after the update.)

And yes, UE will not ask an user to move its configuration files to a new location. I have never seen a program that does that. Every program I have ever used continues to use the existing configuration files even when a new version would create it on a completely new installation in a different directory because of requirements of new operating systems. Well, WinXP is not new ANYMORE, but it was in 2002 as Win2K was in 2000.

All the configuration files are created or updated by the application itself and not by the installer. Only the program really knows what it needs. Also the program must completely handle the configuration file itself or multi-user environments (more than 1 user on 1 computer) will never be supported when only the user who installs the program get updated configuration files. So not the installer updates the INI, the key mapping config file, the menus and toolbars, UltraEdit does it on first start after upgrade for every user if every user has it's own INI (and for every INI if a user like I have more than 1 INI with also multiple *.mfg, *.tfg, *.pfg, ...). Because UE handles the config files, they are also never uninstalled by the installer. The installer does not know where the config files are stored. The uninstaller Total Commander is a little bit better because it asks the user if he wants to uninstall only the program files or also the 2 configuration (INI) files of TC. But even the uninstaller of TC does not uninstall personal menu/toolbar configuration files and INIs of TC not stored in one of the default locations. That's the job of the advanced user, who created these extra files.

For installation of upgrades (version number increases by at least 0.10 = major version increases or minor version increases by 10) always an administrator account should be used because the new version could need access to HKLM to register new features like the SSH/Telnet OLE control.


To Manni and Bernie:

If with a restricted account UE v10.20 or higher really does not use the uedit32.ini in the correct user specific application data directory although the APPDATA environment variable of the restricted user account points to the correct directory and the directory is not write-protected and also really no other configuration files exist in the program directory of UE or the Windows directory and UE is surely also started without /i= command line parameter and no UEINIDIR is set then please report this to IDM so the developers look into it and fix it. You can use Filemon and Regmon with Include filter set to uedit32 from SysInternals to see what's going on at start of UE v10.20+ with a restricted user account.
Readme.txt of v12.20a contains following interesting line about the issue discussed above:

v12.20a 2006-10-26
     - Fixed issue with INI file using windows directory when Admin user

The problem existed only for the default administrator account of Windows XP, not for another account with computer adminstrator rights as I use since I have Windows XP.
Best regards from Austria
Dears, thank you for this interesting thread. A bit sorry for all the animosity in it though.

I had the same problem where UltraEdit would start using the Windows directory to store it's ini file when my account was temporarily granted admin privelages (to resolve another unrelated issue), and then I couldn't change my settings anymore :S

Well, will now use the environment variable and expect that'll solve my issue. Thanks for the tip! :)
Sorry to labour the point, but what is the situation as of version 14.20.1.1008? Do you still need the environment variable?

I've tried the above version and it still appears to ignore Documents and Settings\<user>\Application Data\IDMComp\UltraEdit. If you remove the INI file from Windows, it merely resorts to default settings.

Will this be fixed?
Since v12.20a UltraEdit the default location for the INI is always %APPDATA%\IDMComp\UltraEdit except when one of the following conditions is true (order is important):

  1. UltraEdit is started with the command line parameter /i="name of INI file with full path".
  2. There is an environment variable UEINIDIR with full path to an existing directory where the INI of UltraEdit should be stored.
  3. There is already a file named Name of UE EXE.ini in the directory of the UltraEdit EXE just started.
  4. There is already a file named Name of UE EXE.ini in the directory associated to environment variable WINDIR.
  5. Environment variable APPDATA does not exist (default for Win95, Win98, Win98 SE) resulting in using directory of environment variable WINDIR.
For Windows NT4, Win2K, WinXP, etc. the environment variable APPDATA is created and set to correct path by default automatically by Windows. However, it is possible to open a command shell window, enter the command set APPDATA= to delete the environment variable for this command shell and then start UltraEdit. That will also result in using the Windows directory for the INI on any Windows.

Well, I have not tested yet if UE v14.20.1.1008 has again a problem with the default built-in administrator account. On my WinXP and also my Vista computer I have full administrator privileges and therefore never need the built-in admin account. On Vista that was not easy, but I finally have had success to get the same rights as the by default disabled built-in Vista administrator account on my Vista computer (= no security problems anymore, but also no protection anymore for malicious programs).
Best regards from Austria
Since UltraEdit v12.20 the location and name of the INI file UE is working with can be found under Advanced - Configuration - Application Layout - Advanced.
12 posts Page 1 of 1