UltraEdit 15.20 - window doesn't come to front when opening files

[AtonedIdealist]

I've just upgraded from 13.x to 15.20.0.1016 (the latest version). However when I open a file from within Windows Explorer (double-click, or right-click and select 'open with'), UltraEdit (which is already open) doesn't come to the front, its window remains in the background and it's task bar tab flashes. I have to manually switch over UltraEdit to view the file (alt-tab or click the tab).

However, if I right-click on a file and use the shell context to open the file with UltraEdit, the program window comes to the front as normal.

Is there a new config with 15.x that makes it behave this way? It's very annoying. I want it to come to front whenever I open a file as I want to view the file straightaway.

[Mofi]

Does this happen also when you use a newly created uedit32.ini instead of the upgraded uedit32.ini?

To verify this copy %appdata%\IDMComp\UltraEdit into the address bar of Windows Explorer and press key RETURN or ENTER to open this directory containing the configuration files with your UltraEdit settings.

While no instance of UltraEdit is running rename now uedit32.ini to uedit32_bak.ini (contains most configuration settings) and also uedit32.in0 to uedit32_bak.in0 (new since v15.20, contains the workspace settings).

Start now UltraEdit which will create both files new with the default settings. Test your problem with opening a file by double click.

If UltraEdit window comes to foreground, the problem is somewhere in the INI file. Open uedit32_bak.ini and delete all groups named [ToolBarState1...] which contain workspace settings of the previous GUI not available anymore. Delete also all groups named [TBCFG...] and [...-SCBar-number].

Save the cleaned INI file, close UltraEdit and copy uedit32_bak.in0 over uedit32.in0 and uedit32_bak.ini over uedit32.ini. Start UltraEdit, open Advanced - Configuration - Toolbars / Menus - Miscellaneous and press the button Clear History. Close the configuration dialog with button Cancel. From time to time the histories should be cleared to reduce the size of the INI file. Close UltraEdit (for clearing the histories in the INI) and restart it.

Now test again if the problem with the flashing button instead of bringing the UltraEdit window to foreground still exists with your settings and with a cleaned INI file. The reason is that Windows does not bring a window to foreground when the application needs too long to respond. Instead Windows flashes just the taskbar button to tell the user to activate it.

Extra hint: Advanced - Configuration - File Handling - File Change Detection contains some settings which can improve perfomance (and save battery life time). You can disable the file change detection completely or what I prefer, have it enabled, but enabled is also the setting Check files for changes only on application focus change. With that option enabled the file change detection is not running as a background thread reading and comparing the file information of opened files every 5 (?) seconds. Your problem could be that this background thread has detected a file change of one of the opened files while another application has the focus and therefore when UltraEdit gets back the focus, it displays first the message, if you want to reload the file or not. This message box could be the reason why the UltraEdit window does not come to foreground when you open a file by double click. With disabling file change detection in the background, this problem does not exist.

[AtonedIdealist]

Thanks very much for the quick and very detailed reply Mofi. I tried the ini file approach you suggest but that didn't fix the problem, so it's not a problem with the configuration settings. I also checked the settings for file change detection and I already had the settings you recommended. For good measure I disabled the file change detection completely, but still the problem remains.

However your comment about the flashing taskbar tab and the window not coming to the front due to the time the application takes to respond is very interesting and I think it's highlighted the reason why it's not working properly. If I right-click on a file and use the shell context to open the file (right-click -> UltraEdit) the file opens immediately in UltraEdit and the window comes to the front. This happens regardless of whether the file is open already or not. Now if I open the same file by double-clicking it or right-click -> open I can see that UltraEdit displays a grey page saying 'Loading Files ...'. This page displays for around 2 seconds, before the file is displayed. This happens regardless of whether the file is already open or not. I presume it's this delay before displaying the file that's causing the problem.

So it seems that the command executed by UltraEdit is different depending on how I ask it to open the file. I didn't see this 'Loading Files ...' message before in my previous version of UE, so presume it's a new feature triggered somehow. Any ideas what's causing this message to display and how I can prevent it?

[AtonedIdealist]

I've just run Process Monitor against UE to see what it's doing in both scenarios. It would seem in the scenario where the 'Loading Files ...' message is displayed it's doing a lot more before starting the activity of reading the file and displaying it. The prior activity consists of :

* starts a new thread which then proceeds to read registry entries and load DLLs
* then starts two more threads which do similar activities
* all 3 threads then exit

Then it continues with the normal processing of reading and displaying the file. Any idea what's causing it to do all this extra work?

[AtonedIdealist]

I've been through the registry looking to see if there's different switches used when making calls to UE but there aren't. They are all:

"C:\Program Files\UltraEdit-32\uedit32.exe" "%1"

When I run this from the command line I get the 'Loading Files...' problem, e.g.:

"C:\Program Files\UltraEdit-32\uedit32.exe" d:\temp\custom.java

So the right-click context menu must be calling UE differently but I can't see it in the registry. I'm using Win XP SP3 by the way.

[Mofi]

I can only write what I think is the difference on what I could see with using Process Monitor of SysInternals when double clicking on a file associated with UltraEdit in comparison to opening the same file via the shell extension DLL when an instance of UltraEdit is already running.

When you double click on a file, Windows Explorer looks into the registry if there is an application associated to files of that type (file extension) for opening it. If this is the case it calls this application with the file as parameter as you have already posted. UltraEdit starts now and makes all the steps it normally does when starting the first time, checking existence of required files, loading the DLLs, reading the INI file, etc. If you have not enabled the configuration setting to allow multiple instances (stored in the INI file), the created instance next looks in the process list if there is another instance of UltraEdit already running. And if this is the case, it passes the names of the files to open to the already running instance via a named pipe and then terminates itself.

The shell extension DLL uses a smarter method. The routines in the DLL first searches in the process list if an instance of UltraEdit is already running. If this is not the case, it calls uedit32.exe like Windows Explorer. But if an uedit32.exe process is found, it opens a named pipe (communication channel) to the already running instance and tells this instance that the files x, y, z should be opened. The instance determines now the necessary futher steps according to the 2 configuration settings you can configure at bottom of Configuration - Application Layout - Miscellaneous.

The fastest method of opening files in an already running instance is to use Drag & Drop as I do which is the reason why I have not enabled the shell extension DLL and have not associated any file type with UltraEdit. I needed to do this temporarily just for testing your problem. And I could reproduce your problem.

I think this is a bug of UE v15.20.0.1016 caused by the changes on the source code for opening multiple files faster with other methods. Please send a bug report email to IDM support.

[Zortag]

Something very fundamental changed in the way UltraEdit looks for files to open in version 15.20 from the command line, compared to all previous releases. I use UltraEdit from the command line at least 75% of the time ("C:\Program Files\UltraEdit\UEdit32.Exe" file-name). With this new version, if the comand line does not pass a full file specification, UltraEdit, randomly decides to open a new file on my desktop ("C:\Program Files\UltraEdit\UEdit32.Exe" "%1"), only sometimes (and thats the truely weird part) it does open the file in the command line's current directory; the vast majority of the time, I get that same "Loading files" message, a new icon pops up on the desktop, and when UltraEdit comes back, it has a blank file somewhere in the "Documents and Settings" tree. UltraEdit does work as expected if the full file specification is passed.

Please tell me that there is a setting I can change to revert back to the old, "normal" behavior, this new way is unusable from the command line.

[AtonedIdealist]

I contacted tech support, but the response wasn't what I was looking for:

Thanks for your message. The "loading files..." curtain is not what is causing UltraEdit to not take focus above the other application windows. In version 15.20, there were changes made so that UltraEdit doesn't take focus each time a new file is loaded inside if an existing instance. There had been several requests from other users to provide this more unobtrusive behavior.

However, we understand that some users may find the previous behavior more desirable. Therefore, we are looking at making this configurable in a future release, or permanently restoring the previous behavior. I apologize for the inconvenience.

It's certainly not what I want to happen and doesn't sound like it's going to be made configurable any time soon. I'm now seriously regretting upgrading from 13.x.

[pietzcker]

I wouldn't be that pessimistic. Of course, user demand plays a role - if you're the only one who cares about this, it will take longer to fix. Some things take time (like extending undo capabilities), others are suggested and implemented right away (like ignoring "tabs to spaces" inside strings). Of course, you can always revert to an older version until the fix is in.

[AtonedIdealist]

Indeed pietzcker you were correct. The issue has now been resolved. I'm very impressed with the service from tech support. I was supplied with an updated build last night that has now resolved the problem I had with the 'Loading files...' message and the window being kept in the background. Special thanks also to Mofi for assisting me with this issue. Great forums!

[coohler]

Issue resolved in 15.20.0.1020. Thanks!