It is right that the
OEM Character Set feature is not working anymore as before since UltraEdit for Windows v24.00 as the code of UltraEdit was revised to make UltraEdit a full Unicode aware application. It still works, but only under special conditions which are as follows:
- The font configured for files which should be edited with enabled OEM Character Set must be Terminal. The feature is not working anymore with other fonts according to my tests as in UltraEdit for Windows < 24.00.
- After startup of UltraEdit and opening a file which should be edited with enabled OEM Character Set it is necessary to enable OEM Character Set for this file activating it also for all other files with a file extension in same group as defined at Advanced - Settings or Configuration - Word wrap / tab settings. In UltraEdit for Windows < 24.00 the OEM Character Set was set after startup of UltraEdit for files with a specific file extension as set on last exit of UltraEdit which means enabled by default.
I think these restrictions are not implemented intentionally. They exist most likely because of the code changes done for making UltraEdit a full Unicode aware application.
I wrote on last Sunday an issue report and sent it to UltraEdit support. I have attached the issue report and the reply I received on Monday below.
It would be good if every UltraEdit user often editing batch files or other files which must be edited with OEM character set reports all
OEM Character Set related issues also by email to UltraEdit support. And it would be good to send also feature request emails related to
OEM Character Set to UltraEdit support like a request to add this command back to toolbar and ribbon customization dialog. The more users report an issue or request a feature the higher becomes the priority for fixing the issue or implementing the enhancement.
The issue report sent by me on 2019-06-24 to IDM support. The RAR archive file is not attached to this post.
UltraEdit is - or better was - the only Windows text editor supporting editing files with a specific file extension like BAT, CMD or NFO using OEM character set instead of ANSI character set for non-Unicode files. This makes (made) UltraEdit the best text editor for editing such files, especially when non-ASCII characters needed to be written also into such files like ÄÖÜäöüß in German batch files with information in German for German users.
Such a file extension based OEM editing configuration could be very easily achieved in the past by
- opening Advanced - Configuration - Editor - Word wrap / tab settings;
- clicking on button Change list...;
- adding a list item with the file extensions bat cmd nfo and clicking on button OK;
- selecting list item bat cmd nfo;
- configuring tab stop, indent and word wrap settings and if wanted also a special font like Courier New in my case with larger font size 14 pt than usually used by me;
- closing configuration with button OK;
- opening any *.bat, *.cmd or *.nfo file;
- clicking on item OEM Character Set in menu or toolbar to enable this handy feature for all files with file extension BAT, CMD or NFO.
Then *.bat, *.cmd and *.nfo files could be edited with interpreting all characters in those files with OEM character set and getting characters typed on keyboard written into file OEM encoded once this configuration was done by the user.
But making this configuration and using OEM character set feature became more and more difficult because of removing first this command from the default menus and toolbars and later even from menu/toolbar customization dialog. However, I found always a solution to have the command to toggle on/off OEM character set feature into the toolbar and posted the necessary steps in forum
here.
But with UltraEdit v24.00 on becoming a full Unicode aware application the feature to edit files for usage in Windows console with OEM character set does not work anymore automatically after opening such a file and only works with special font setting at all.
I created today a configuration for you derived from my configuration for 32 bit UltraEdit v26.10.0.38 to make it easier for your developers to look on this feature. The attached RAR archive file contains:
- batch_settings.uec which is a backup of the special configuration with uedit32u.in0, uedit32u.ini, uedit32u.rb0 and my theme file Mofi.ue-theme.These four files are additionally also in RAR archive file.
- Test.bat stored in directory C:\Temp on my Windows 7 PC.
- batch_configuration_settings.png with a screenshot of the special settings configured by me for *.bat, *.cmd and *.nfo files.
- batch_oem_character_set_disabled.png with a screenshot showing how a batch file with ANSI and OEM characters looks like after opening the batch file in UltraEdit after starting UltraEdit.
- batch_oem_character_set_enabled.png with a screenshot showing how the batch file with ANSI and OEM characters looks like after enabling manually via the toolbar symbol the OEM character set feature for the batch file.
A batch file opened in UltraEdit up to version 23.20 was displayed automatically with OEM character set and typing a non-ASCII character resulted in inserting the character OEM encoded into the batch file. I used font
Courier New in the past with font size 14 for *.bat, *.cmd and *.nfo files instead of
Courier New 10 pt or 12 pt respectively Dina 10 pt. The custom toolbar contained the command with tooltip
Show font with OEM character set mainly as visual indication for me on which file OEM editing is enabled at the moment. I did not really click on this command to toggle OEM character set editing as this was not really necessary most of the time.
But the INI setting
Force OEM2=1 is not loaded anymore by UltraEdit since version 24.00. The OEM character set feature is always disabled for files of second file extension group after starting UltraEdit and opening a batch file. So I must click once on blue underlined
A in my custom toolbar after opening a batch file to enable OEM character set for the batch file.
Further the OEM character set feature is not working with font
Courier New or any other font than
Terminal. I really have no explanation why it works now only with font
Terminal. Other fonts like
Modern and
Roman on which the font settings dialog displays as script also
OEM/DOS do also not work with OEM character set enabled as expected.
Please do following to better see what I mean:
- Extract the files in attached RAR archive best to directory C:\Temp.
- Start 32 bit UE 26.10 and restore my configuration from configuration backup file batch_settings.uec using Backup/restore user customization.
- Open C:\Temp\Test.bat if not opened automatically.
- The file is displayed as captured to batch_oem_character_set_disabled.png with ANSI characters correct displayed and OEM characters not correct displayed indicating that OEM character set is not active as it can be seen also on blue underlined A symbol in custom toolbar.
- Click on blue underlined A symbol in custom toolbar and look what happens respectively look on image batch_oem_character_set_enabled.png. Now the ANSI encoded characters are displayed wrong and the OEM characters are displayed correct as expected by me. And the characters ÄÖÜäöüß are inserted correct OEM encoded now on typing them on my German keyboard. It can be seen also that content of Test.bat is displayed with a different font (Terminal instead of Courier New) after manually enabling the OEM character set.
What I do not understand is:
- Why is Force OEM2=1 ignored on loading uedit32u.ini?
The setting is stored with value 0 or 1 depending on OEM character set currently disabled or enabled on exiting UltraEdit. So it is just not loaded on start of UltraEdit.
- Why does OEM character set feature work now only with font Terminal and does not work anymore with any other font configured for files with file extension bat, cmd, nfo and supporting code page OEM 850?
The reply received from IDM support on 2019-06-25:
Thank you for your message and the attached archive. I can reproduce the issue you've described here and will ask our developers to investigate and correct this.
I'm sorry that I don't know the answer to either of your questions, but I will check with our developers and get back to you with the information I'm provided. I will also be sure to let you know when we have an updated build that we believe resolves this issue.