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

Two- and three-way text compare and merge issues.
6 posts Page 1 of 1
I upgraded UC to a few days ago. Since then my command line call doesn't work as expected.

I use "uc -t -ne file1 file2" at the command line to compare two text files and view only the differences by default. This used to work okay in the previous version. Now this command defaults to just differences, but shows nothing. If I click on "view all" I see all the lines, but no differences are highlighted.

Did something break in this version?

Thanks, Mike
I tested with 32-bit UC Professional v15.20.0.11 a text comparison of 2 ASCII/ANSI files by using uc -t -ne C:\Temp\Test.bat C:\Temp\Test2.bat and started uc.exe and halted execution until UltraCompare GUI application was exited by me. GUI UC displayed correct just the differences between the two batch files (additional lines and differences within some lines). My default is displaying all. So parameter -ne was recognized correct although being specified on an uncommon position on the command line.

Starting GUI version with using uc.exe -ne -t C:\Temp\Test.bat C:\Temp\Test2.bat (directly start GUI version and -ne at common position on the command line) worked also perfect on Windows 7 x64.

I must add that I started uc (.com as used by Windows command interpreter according to environment variable PATHEXT and found first and .exe as explicitly specified by me) with full path from command line as I have removed UltraCompare program files folder from system environment variable PATH because I don't like it having directory paths defined in PATH not really needed by me on working within a command prompt window.

I suggest to check your PATH variable if there are multiple UltraCompare directories defined.

I suggest also to open in UltraCompare View - Themes - Manage Themes, select tab Compare and check the colors defined for displaying text differences in the UltraCompare theme used by you.

I don't have the 64-bit version installed on Windows 7 x64 to test if the 64-bit version produces also the expected result like the 32-bit version.
Best regards from Austria
To mqg999,
I have tested with UC x64@Windows 7 SP1 x64 with command line "uc -t -ne myfile.1 myfile.2" and for me working fine here ... Only differences were shown ...
It's impossible to lead us astray for we don't care even to choose the way.
Thank you for your reply. First, I'm using the 64-bit version.

The theme was not the issue. The UI showed "0 differences" in the status bar. I failed to mention yesterday that I was occasionally receiving a "Unfortunately, the files you're comparing exceed the available memory. The comparison will be aborted." message. Didn't happen all the time but only at times. I decided to restart my computer and my problem is now resolved.

It would be interesting to know why UC perceived a memory issue. I had many other apps running just fine at the same time. And the files I was comparing were tiny.

Thanks, all good again.
"Not enough memory", or a bad_alloc exception as named in C++, can have many reasons:

  • There is an error in code of the application (bug) - must be examined by a responsible software developer to fix it.
  • RAM is heavily fragmented and therefore there is much available memory, but not much in a continuous block - reboot of machine helps.
  • RAM is defect, a single bit failure (stuck 0 or stuck 1) causes abnormal code execution from time to time in various applications - executing the RAM test of the computer's manufacturer could be used to check that.
  • Hard disk is defect and therefore the code of the application is not loaded into RAM as it was originally stored on hard disk - executing full hard disk check could be used to check that.
  • An application is not written well and takes more and more GDI objects until limit of 65536 (default) is reached which is often not bad for already running applications, but for newly started applications - reboot of machine often helps and of course not using the application using more and more GDI objects.
  • An application is not written well and takes more and more user objects which is usually a problem for the not well coded application only - restart of application often helps.
  • An electromagnetic interference caused temporarily a memory corruption resulting in abnormal code execution. This reason is not possible to detect without special measurement equipment and can be detected at all only when abnormal code execution happens frequently caused by electromagnetic interferences.
  • Others ...
The number of GDI and user objects used by a running process can be viewed on processes tab of Windows task manager or in Sysinternals Process Explorer after adding the appropriate columns.

Conclusion: Abnormal program execution is interesting for further examination only when it occurs several times within a certain period of time. The time period depends on device and importance of the application running on the device. A mobile phone for usage by people is completely different to a power plant control or protection device in regard to failures within a period of time.
Best regards from Austria
FWIW, I just ran into this "files you're comparing exceed the available memory" problem trying to compare two small files (about 70 lines/2KB each) using:

- UES x64 v16.20.0.6
- UC Lite x64 v16.00.0.27

and found that a a restart of the computer solved the problem for me, too. No idea what the root issue is/was, but I do tend to leave my computer running without a restart for weeks.
6 posts Page 1 of 1