It is of course no good idea to start 275 instances of UltraEdit whereby each instance has to wait until previous instances removes the read lock on INI file before being able to read from INI file to find out that a single instance of UE should be used, passing the file name to already running (first) instance and then exit current instance.

First, I suggest to not open any of the files or just one of them and use Find in Files and Replace in Files.

Second, much faster is opening all the files from within UltraEdit using File - Open or even better File - Quick Open. Quick Open supports wildcard patterns to open all files matching the pattern from selected directory or a directory tree starting from selected directory.

Another method to quickly open a set of files is starting UltraEdit and then drag & drop the files selected in file manager (Windows Explorer if not using something better) over main window of UltraEdit to open all those files. If file manager window is maximized and therefore UltraEdit main window is not visible on screen, the mouse pointer with left mouse button hold must be moved over the UE icon in Windows task bar, stay there for 2 seconds which results on Windows sending the message to UltraEdit to become active and to foreground, and move mouse pointer while still holding left mouse button over UE main window and leave the left mouse button there.

UltraEdit supports also wildcard patterns on command line to start and open all files matching the pattern.

And finally, UltraEdit supports also opening files from a list file containing one file name with path per line. So you could also write all file names with path to a list file and start UltraEdit with command line parameter /f"Name of list file with path". See in help of UltraEdit the page Command Line Parameters for details about command line parameters supported by UltraEdit.

Opening 400+ files for editing! How do you navigate between all those opened files? It must take you minutes to identify a file in large list of opened files.

I suppose that you don't really edit manually those files. I suppose you run a find or replace on all opened files or run a macro or script on all opened files. But there are the commands Find in Files and Replace in Files and macros and scripts can be written to work with a list of files to open, modify, save and close each file individually instead of first opening so many files and then run the macro / script on all those files.

The multi-document interface is designed for human operated applications and not for automated tasks. The amount of memory and time needed for each file for features useful for human users (undo, code folding, syntax highlighting, line change indication, etc.) but useless on automated tasks makes working with so many opened files slow.

Of course you could disable all those features by disabling usage of temporary files, syntax highlighting, code folding, line number counting, XML parsing, line change indication, ... which would decrease time required for opening hundreds of files dramatically. But this UltraEdit would not make you happy most likely on manual editing.

Do you know that you can configure a project in UltraEdit to work on many files not opened all at once?

Hi,
I agree with sklad2, working with 20 open files isn't anymore fast enough as it was years ago.
We store all source code on network drives due to company policy.
My main problem: UE is not responding ("hangs") for about 5 sec from time to time after having navigated to or saved a middle size file (above 5000 lines), when having 10+ files open.
I open several files read-only - missing feature: add to project in read-only mode.
UltraEdit Professioneller Text-/HEX-Editor (x64) - on Windows 7
Version 23.20.0.28

Miklos wrote:... from time to time after having navigated to or saved a middle size file (above 5000 lines) ...

This is an indication that from time to time the network access or the server is not responding immediately on a file access triggered by UltraEdit.

For example with File change detection being enabled as by default, UltraEdit periodically and on switching focus to another file makes a file system access to get file status (file size, last modification date, ...) to determine if the file was modified while opened in UltraEdit. Disabling this feature avoids all those file system accesses being network and server accesses on a file not opened from a local storage media.

Another common source for unexpected delay on accessing a file is an anti-virus application updating itself in background multiple times within working hours. Some anti-virus applications block any file access while switching from previous to new database which can take some seconds and the user is wondering why an application is not responsible for some seconds. Applications like UltraEdit having opened multiple files which are often permanently modified and writing those modifications to storage media (for not losing too many changes on a crash or unexpected power loss) are more affected for such file system delays by background process, heavy network peaks, short high server loads, etc. than other applications loading once everything into RAM, modify it there and save the data back to storage media only on file save.

There is the topic Painfully slow response when connected via VPN with suggestions which settings to change to decrease file accesses to a minimum.

Some of those file accesses are done by UltraEdit already within separate threads to let main thread be responsive. But others still cause sometimes noticeable delays. Those should be encountered by users and reported to IDM support by email, best with a suggestion how to improve UE/UES for a specific issue.

The free tool to use for analyzing the cause of reproducible delays on responsiveness is Process Monitor from Sysinternals (Microsoft). But it is not really possible to find out the reason for delays on responsiveness with that tool when they occur only from time to time. You must have luck to log registry, file system and network accesses with nearly no other process excluded with Process Monitor just while having a delay on responsiveness in one application not occurring frequently.

But I can confirm that the stylish user interface of UE for Windows v23.20 takes much more time for redrawing than the former GUIs, especially those using MFC 6.0 (UE for Windows < v15.00). On my own tests I could see that my UE GUI configuration using Windows Classic desktop theme and UltraEdit Classic theme in Windows 2000 look (more precise in Windows 95 look) with minimalistic workspace makes really a big difference in window refreshing rate. I'm always shocked how much slower UltraEdit is with the default very stylish interface when using for a test the default settings in comparison to my settings on my quite old computers. Well, I favor always functionality over look. The best application for me is the application which I can use fast (by using mainly keyboard). But for others the look is more important than everything else. The majority of UltraEdit users wanted a stylish look which of course needs CPU power (= time for calculation) according to the results of opinion polls in the last 5 years from what I get informed by IDM support after my asking by email. With my interface setting UltraEdit can fill most rectangle areas with one background color (no pixel color calculation needed) and write the text in one color (no cleartype active) over it. That is fast. Shading and fading effects with special cleartype text drawing and icons with alpha channels need of course much more time because for each pixel in window the color must be really calculated first. And UHD or high resolution screens have really a lot of pixels.