Windows 7 (Beta/RC) issues with UltraEdit

[rseiler]

I've noticed for v15 (and its hotfixes) in Win7 beta and RC that UE will not finish its install wizard unless I go well out of my way to elevate the install. It puts up a message eventually saying that I don't have sufficient privileges, at which point I have to cancel the install. Oddly enough, the new version is installed after all that, so go figure.

I say well out of my way since it's not an EXE but an MSI, and right-clicks on those don't show "Run as administrator."

Is there a particular reason for it 1) being an MSI and 2) requiring elevation? Please fix one or both things.

Note: I do have UAC enabled.

I found this, which adds a "Run as administrator" to an MSI file's context menu. Works in Vista/Win7:
http://www.symantec.com/connect/downloa ... menu-vista

[dynobyte]

Here's another oddity which I don't remember in previous versions. This is Win7 RC 64bit, and UltraEdit 15, now updated to 15.10, I did a completely fresh install on a new PC I built when the Win7 RC came out. I did not import any customizations or preferences, I re-created everything from scratch.

I had no problems and everything works fine and I love some of the changes. My toolbars are pretty customized, as are my wordfiles, but other than that it's a pretty standard installation. Preferences are in AppData rather than registry; I accepted most of the installation defaults (I may have declined r-click explorer integration on 15.00 but allowed it on 15.10). UE is the default handler for txt, log, ini, all those file types in the left column of the splash screen.

Here's the oddity. If I double-click an associated file in an Explorer window with UE running, it loads into UE immediately, as I would expect; HOWEVER there's also about 5 or more seconds of cursor hourglass anywhere on the screen except within the UE window. This hourglass does not affect my ability to work on the newly loaded file immediately, even while that hourglass keeps spinning outside the UE window.

If I run task manager to look for clues, I see that a SECOND PROCESS of UltraEdit starts up when I double-click the text file in explorer, even while the file opens in the instance of UE that was already running. After a few seconds, this second process of UE disappears, as does the hourglass cursor. I do NOT have 'allow multiple instances' enabled in preferences.

If I DRAG a file from an explorer window ONTO the UltraEdit window, as opposed to double-clicking it in explorer, none of this second-process or hourglass stuff happens. Ditto if I load a file from within UE using the open dialog box--no hourglass. Only double-clicking in Explorer causes it.

Finally, I also get 5 seconds worth of hourglass pointer some of the time (but not all the time) when I exit the program altogether. In other words, the UltraEdit window closes, I can do anything I want, but there's an hourglass pointer spinning for a number of seconds after the program has visibly closed -- again, it doesn't interfere with doing other things. So far I have not been able to observe anything in task manager that correlates with it.

The computer I was using when I made the original post in this thread is now backup-only, but it also got a fresh install of Win7 RC 64-bit, and I tried all this on that one, too. Same exact behavior: hourglass if you double-click a file to open it, no hourglass if you drag a file onto the UE window. And same hourglass some of the time when you exit the program. Happens on 15.00 or 15.10, both builds, both computers.

I call these oddities because they don't rise to the level of 'problems' and because I haven't seen anything similar in previous versions of UE or Windows. I don't think this happened with UltraEdit 14 on Win7 64-bit beta 7000 (but I don't guarantee my memory on that one). Prior to this I've always used 32-bit Windows. I'm just curious if anyone has a good explanation.

[Mofi]

The behavior you see is not really suprising me. We already know that Microsoft's Anti-Virus-Guard (AVG) does not like it how UltraEdit accesses its INI file. Don't know why an anti-virus program blocks accesses to a text file. However, let me explain what happens when you double click on a file associated with UltraEdit.

The first part is identical for every opening of a file with a double click by any application.

First Windows (Explorer) looks into the database called Registry under HKCR if the extension of the double clicked file is registered. If this is the case and a key is assigned to the registered file extension, it searches for this key and looks if a subkey exists which contains the information which application should be used to open this file and with command line parameters should be passed to this application.

If no special command line parameters are specified, Windows checks now the type of the executable (real 16-bit DOS application, 32-bit console application, Windows application, etc.) to determine which command processor should be used and also how the full file name should be passed as command line parameter when calling the application (16-bit applications need old DOS environment and 8.3 format for the file names, 32-bit console applications need to be executed in the 32-bit command shell environment, run application "as administrator", run application in a special environment (older OS), etc.).

Now after Windows has determined the environment needed for the application and established it, it calls the application from within this environment and passes the name of the double clicked file as command line parameter to the application. Additionally Windows tracks some additional data in the registry like that the file with extension ??? was opened with application XXX and application XXX was started and, ...

Okay, so now uedit32.exe is started by Windows (Explorer). Well, that needs some time because the EXE file must be loaded into RAM, also all static DLLs used by this application are loaded and the anti-virus software scans all those file accesses and the files, and so on. Of course this process is done much faster when UltraEdit was started once after Windows start because the file caching system of Windows already keeps all file data in RAM (normally).

Now the UltraEdit specific part comes.

The second instance of UltraEdit must first, after being loaded and started and all DLLs are loaded, evaluate the command line parameters. There could be /fni or /fno or /i="...". If no such special command line parameter exists, it has to check for environment variable UEINIDIR. If such a environment variable does not exist, UE has to search for uedit32.ini in the EXE directory (where I have uedit32.ini), in the Windows directory (for downwards compatibility) and finally in %appdata%\IDMComp\UltraEdit\ where UE usually finds now finally uedit32.ini.

Now the second instance maybe first searches in the INI file for Version= under [Settings] and other version information because maybe this is the first start after an update and some settings and configuration files must be updated or not. Then UE can search for Use Registry= under [Settings] to determine if all the settings are store in uedit32.ini or in the registry.

When the are stored in the INI file UE can search now in uedit32.ini for Multiple Instances= under [Settings] to determine if it has to check for an already running instance of UltraEdit or not. In your case it has to do this and so it looks into the list of running processes if there is one having the same image path (full name of the EXE) as this instance of UltraEdit. If this is the case it has to send with a message this first instance of UltraEdit the (remaining) command line parameters passed from Windows to this second instance. After that was successful the second instance can terminate.

I don't know what UltraEdit does additionally after sending the file name to the first instance of UltraEdit before terminating. It could close itself immediately without the need to save anything into any configuration file because this instance should have not modified any setting.