Does UltraEdit really freeze or does only the main window loses its focus because the color dialog is opened but you can't see it?
You can check this by simply pressing the ESC key when you have clicked on Insert Color and the color dialog is not shown. When after ESC the UltraEdit window has again the focus and you can continue working then the reason for the problem is wrong coordinates in registry for the color dialog which is the same issue as
List Lines Containing String - quit working for the color selector dialog.
To fix this problem delete following key in the registry with Regedit:
HKEY_CURRENT_USER\Software\IDM Computer Solutions\UltraEdit\ColorSelector
or modify the binary values in the default key for example to:
ca 02 00 00 99 00 00 00 e6 03 00 00 da 01 00 00
For a full explanation of the problem I post here the email I sent to IDM support.
Dialogs opened in outer space
Comment: Fixed with UEStudio 6.00 and will be fixed with next major release of UltraEdit. Now the 4 coordinates are stored in the registry in a hex value named "rect" instead of the default value as suggested.
Since UES v5.50 and UE v12.00 some dialogs are resizable and the properties for these dialogs are saved in the registry. Although I like the idea of resizable dialogs and adjusted it in size and position best for me, I'm confronted a few times in the last 3 months with the problem that a dialog is opened in outer space. The main window loses its focus but the dialog is not visible. I have to press ESC to close the hidden dialog and delete the whole branch key of the appropriate dialog in the registry.
Yesterday
(= 30.07.2006) I looked into it and found out that the DEFAULT key @= which is by Windows default always a string key is converted by UE/UES to a binary key which then contains 4 32 bit unsigned values: left x/y and right x/y coordinates.
Yesterday I exported the key of the color selector dialog opened in outer space before I deleted the whole key to get the dialog back. Here are the values of the key which caused the dialog to be opened hidden.
@=hex:00,14,00,00,67,01,00,00,00,14,00,00,6f,01,00,00
The x values are identical and the y values have only a difference of 8. It's impossible that I have resized the color selector manually to these coordinates. So there must be a situation where UE/UES destroys the values itself. And I found this situation.
This always happens when the default key is by Windows converted to a string key. At Win98 this happens when the keys and values are imported from a reg file or the whole registry is recreated new which I do sometimes to reduce the size of the registry files (really delete the deleted keys). I looked further into this issue and detected that Windows automatically creates the default string key @= when creating a new branch key. With Regedit the type of the key cannot be changed later manually. So the default key with the 4 coordinates cannot be created manually and at Win98 Regedit will also not change the type of the key when importing it from a registry file to the default binary key that UE/UES needs. So at Win98 the importing of the coordinates of a dialog from a registry file always fails. Only WinXP (and I guess also Win2K) supports changing the type of key when importing a registry file. At Win98 it's also impossible to delete the default key with Regedit. At WinXP a deletion of the default key with Regedit is possible, but it automatically creates a new default key as string. The result is that whenever the default key changes the type back from binary to string, the dialog with the properties stored in the registry cannot be opened anymore and at Win98 the whole key of the dialog must be deleted to force UE/UES to create the whole key with useful default values again or at WinXP the hopefully former exported keys are imported again from the registry file.
Conclusion: First UE/UES should write useful coordinates into the default key when it changes the type from string to binary, but the other binary keys already exist. This would solve the problem that the dialogs are not visible. And further I suggest that the coordinates are not saved in the default key because Windows has a strong tendency to a string type for the default key.
Next it's also possible that a user has either temporarily more than 1 screen or changes the resolution of the screen (notebook TFT and desktop TFT with a docking station). So it's also possible that the stored coordinates of the dialog are outside the current screen and that would also lead to open the dialog in outer space. So UE/UES is always forced to check the currently stored coordinates of a dialog if it is at least inside the currently available and visible screen area (1 or more screens) or better inside the UE/UES main window.
