Hi,
I've a problem with UltraEdit 17. Today I've installed the new version (recently I've used V16).

Every time when I try to open a file with double click following system message is shown:

"There was a problem sending the command to the program".

But a little bit later UltraEdit starts up and opens the file. There is no problem when UltraEdit is already running.

The problem occurs also if I try to open a .txt file via ShellExecute() from another process. Due to my knowledge this problem is caused when a program does not respond correctly to the system messages which are posted to a registered application at startup.

I'm using Windows7 (x32) Ultimate, UAC is enabled. All other stuff on my computer works fine. UltraEdit 16 works without any problem.

Has anyone the same problem or much better any ideas how this annoying problem can be fixed?

Just for information: I've already tried to remove all .ini stuff, switch OFF DDE in UltraEdit. The problem is still the same.

First, I suggest to delete the existing file assocation with Advanced - Configuration - File Associations in UltraEdit and then add it again.

If re-registering the file association does not work, I suggest to use Process Monitor from SysInternals and log registry and file system accesses. Perhaps you can see what is causing the error message.

Mofi,
Thanks for your reply, but I think you have not got the point.

a) The registry keys are all there
b) UltraEdit is launched and the file is opened (just the annoying message is shown)
c) DDE works perfect when UltraEdit is already running

For clarification: when a file gets opened via double click and a DDE server is stated in your registry (as it is present for UltraEdit.txt) the application receives a DDE command from the Windows Shell. UltraEdit is programmed with MFC & BCGP UI Toolkit. So there must be an OnDDECommand() handler in the CWinApp which has to handle the DDE command correctly. If this is not done the windows error message is shown.

But I'm a little bit astonished that nobody else has the same problem. If there is something wrong in the core implementation the problem should occur on many computers.

I'll try to check it with Process Monitor when I've access again to my private computer (in the evening).

I suggested to delete current file assocations and assign the file associations again because I think the problem is the either how the files are registered or the registry is partly corrupt. The registry is a database file as you might know. I have had already 3 times (once on my office computer, two times on other computers) that a registry key was visible in the tree in Regedit (key correct indexed), but the registry key itself was not accessible (record damaged).

Also UltraEdit itself registers files without DDE by default. I monitored the file association of .txt done by UltraEdit v17.00.0.1025. Here are the changes made by UltraEdit in registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt]
@="UltraEdit.txt"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt]
@="Textdatei"
"Old Default"="txtfile"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open\command]
@="\"C:\\Program Files\\IDM Computer Solutions\\UltraEdit\\uedit32.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print\command]
@="\"C:\\Program Files\\IDM Computer Solutions\\UltraEdit\\uedit32.exe\" /p \"%1\""


But it is also possible to register file extensions with DDE. To do that first Use DDE for file associations must be checked at Advanced - Configuration - File Handling - Advanced and applied, and then the file extensions must be registered. That adds to registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt]
@="UltraEdit.txt"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt]
@="Textdatei"
"Old Default"="txtfile"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open\command]
@="\"C:\\Program Files\\IDM Computer Solutions\\UltraEdit\\uedit32.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open\ddeexec]
@="[open(\"%1\")]"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open\ddeexec\Application]
@="uedit32"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\open\ddeexec\topic]
@="System"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print\command]
@="\"C:\\Program Files\\IDM Computer Solutions\\UltraEdit\\uedit32.exe\" /p \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print\ddeexec]
@="[print(\"%1\")]"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print\ddeexec\Application]
@="UEDIT32"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\UltraEdit.txt\shell\print\ddeexec\topic]
@="System"


I have never done any file association before because I use as file manager Total Commander and open files to edit with UltraEdit with pressing F4 (single file, UE not already open), use a button in the customized toolbar of Total Commander (multiple files, UE not already open) or use drag and drop (one or more files, UE already open).

But now for helping you on this issue I registered .txt with DDE and then tested what happens if I uncheck Use DDE for file associations after making the file associations. The result is a File not found. error message created by DDE service. It looks like the configuration setting Use DDE for file associations does not only determine if file associations are made with the DDE keys or not, it also determines if DDE is internally in UltraEdit enabled or not. So your problem is perhaps caused by not enabling Use DDE for file associations.

PS: I'm using Windows XP SP3 x86 (32 bit).

Meanwhile I've fixed the problem.

To resolve the issue, I did the following actions:

- Uninstalled UltraEdit 17
- Manually removed all UltraEdit stuff from the registry (CLASSES_ROOT & CURRENT_USER)
- Switched OFF UAC
- Rebooted
- Installed again UltraEdit 17
- Performed file type registration with UltraEdit 17 (startup dialog)
- Tried to open a .txt file via double click in Explorer -> it worked
- Switched ON UAC again
- Rebooted
- Tried to open a .txt file via double click in Explorer -> it worked -->

I'm sure that it is a problem from UltraEdit. Something might be wrong when UAC is enabled during install & file type registration or when installing UltraEdit 17 without manually un-installing UltraEdit16 before.

BTW: currently I use UltraEdit without DDE. Opening new edit views via double click from explorer to a .txt file is much slower as with DDE but I'm happy that the annoying message box is gone.

I was having the same problem, and after re-doing the file associations, I noticed something odd. I think the reason re-doing the associations works is because the new ones don't actually use DDE.

The registry key UltraEdit now writes is "ddexec" not "ddeexec" -> spelling error -> no DDE!

If I fix the spelling error by hand, the problem comes back.

For now I've just shut off DDE in the file associations, as it doesn't seem to work.

I'm on Win 7 Pro x64

Six years on, I came across this post in the course of investigating the potential benefits of enabling DDE within UltraEdit Text/Hex Editor (x64) Version 24.10.0.35. Since I don't think I've ever run UltraEdit with the DDE bits enabled, and been generally happy with its performance, I have never felt the need to enable it.

I am investigating the matter today, eight years into my use of it as my primary general purpose text editor, because I am making other significant changes to compensate for a drastic shift in my workload, from primarily Windows to primarily Linux (Linux instances hosted on a client's AWS EC2 instances), and I noticed it when I visited every page in the advanced settings dialog box, in search of a setting that I accidentally changed that is causing UltraEdit to begin hiding the active toolbar.

BTW, I am intrigued by the mention of DDE making file opening from the Explorer more responsive, since I've never noticed any lag, especially once an instance is open. Nevertheless, I am not especially shocked, since I have actually measured instances in which DDE outperformed other methods, e. g., performing mail merge between a primary document in Microsoft Word, with Excel as the data source. In particular, in the late 1990's, I had occasion to compare DDE in Windows 95 against the very same process, using the same two files, on Windows NT Workstation 4.0. To my astonishment, Windows NT Workstation significantly outperformed Windows 95! This told me that the Microsoft engineers were still actively maintaining DDE.