Hi,
currently in use: UltraEdit for Windows 24.20.

Since some updates UE does not start anymore.
It is configured to open the last project I worked on.
But some files on the project are on file shares which are not available at start of UE.
It seems, the timeout of the network for the shares is not processed correctly.

With the last releases it still took some time to start when the file shares were not available - but it started.
Now, it does not (permanently working).

Edit: After 8 minutes loading was completed.

Can anyone confirm?

Well, UltraEdit does not need to know the network timeouts. UltraEdit calls a Windows kernel function to open a file. If the file is not on a local disk, the called Windows kernel functions calls itself another Windows kernel function which makes the necessary network accesses. The TCP/IP stack handles the network timeouts which are usually quite long (more than 30 seconds per network access). So it can take several minutes until the approach to load all files previously loaded on last exit finished on having a connection to a network, but not to the machine with the share on which the files are stored. It makes a huge difference if there is no network connection at all or there is a network connection, but not to the server hosting the files.

It would be of course possible to improve file handling on reload for such rare use cases on which files from a network share should be opened on start which is not available yet while a connection to a network exists. UltraEdit could check before opening a file if the file's path is a UNC path. In this case the file open could be done for this share by a thread running in background to more quickly finish the main startup thread. And for a file with a drive letter UltraEdit could look up if this drive is an available local drive or a network drive. In case of a network drive the file opening task could be also done in the separate thread. So local files are re-opened on start immediately and all files on a network drive/share are loaded by a background thread.

But is it really good if a user starts UltraEdit, gets some files immediately displayed, thinks the loading is finished, starts working and suddenly some seconds or even minutes later depending on network accessibility and network speed more files are opened surprisingly with no appropriate user activity?

I would not be happy about such a behavior which results in fast startup of UE even on re-opening network files currently not available at all or on which it takes longer to load them. I would not be happy when I have started already editing, run a Find/Replace in opened Files, run a macro/script, etc. and suddenly there is one more file opened and become active file.

Well, the main startup thread could wait for example for 10 seconds for the finishing of the separate thread used to open network files before giving control to user and the separate thread silently in background stops opening network files 10 seconds after being started even when the Windows kernel finish after several seconds a file access positive. This could result also in a confusing situation for the user when the network share is available, but it network speed is currently low. Then some network files could be opened on startup within 10 seconds maximum wait time and others not. The user could be irritated in this case why are loaded just some and not all network files.

Conclusion: Whatever a programmer of an application implements to get a quick responsive user interface while on startup network accesses must be done which can take longer as usual or fail at all after long timeouts results in practice always in a confusing situation for the user not knowing what is going on in background.

Hi,
thank you for the long explanation.

The only hint I have: In previous versions the behaviour was different.

But as you described it, this may also come from a change in Windows behaviour - since UE only calls Windows functions.

So we (I) have to live with this - unfortunately.

The text file changes.txt in program files folder of UltraEdit contains for v23.20 the information:

• Near instantaneous file loading
  • Improved performance for normal file open, drag-and-drop, project reloading, etc.
  • Makes startup exponentially quicker when reloading multiple files

I don't know anything about the changes made to faster reload files previously open. It could be that the changed code for faster reloading files on startup causes in uncommon use cases like yours the opposite, the startup time dramatically increases because of the loading approaches of not accessible files.

I suggest to report this issue to IDM support by email for investigation by the developers with adding following files:

1. The *.prj and *.pui files of the project and a few files which can be loaded quickly and a few which are or not accessible share packed altogether into a ZIP or RAR archive file.
2. The entire content of folder %APPDATA%\IDMComp\UltraEdit\ packed also into the ZIP or RAR file containing startup.log and all other configuration files.
   You can omit the subdirectory wordfiles all files in this directory are 100% identical to the wordfiles directory in program files folder of UltraEdit.

And the email should contain Information about network connectivity on starting UltraEdit with that long startup time.

1. Is the computer connected to any network at all or completely disconnected on startup of UE?
2. Can the machine with the share containing the files to reload be pinged successfully with ping ComputerName executed from within a command prompt window or is it not reachable at all.
3. The output of a trace route execution would be perhaps also useful.
   Run in a command prompt window tracert ComputerName >"%USERPROFILE%\Desktop\TraceRoute.txt" and add the content of file TraceRoute.txt created on your desktop also to the email as text, or alternatively as file also added to ZIP or RAR file.
4. Or is the computer reachable fast but the files cannot be opened by UltraEdit because of using a different user account which does not have read permissions on that share?

You might also download and extract free tool Process Monitor of Sysinternals (Microsoft), run it while starting UltraEdit, save the logged file/registry/network activities during UltraEdit startup in native Process Monitor log format, and attach this file also compressed with ZIP or RAR to the email (if not being too large).