Community

When you use TextPad to open a *.reg file in the Unicode Format, and save it (even without any editing) then the Registry Editor refuses to entertain it thereafter because it now sees it as a binary file.
The following is a typical error report:

The specified file is not a registry script. You can only import binary registry files from within the Registry Editor.

But even importing from within the registry editor fails!

I searched the web for the solution to this problem and the common factor was the culprit "TextPad"
TextPad fails to apply (and on saving REMOVES existing) Unicode marker strings at the beginning of a UTF-16 file:
namely 0xFF,0xFE for Unicode
& 0xFE,0xFF for Unicode (BigEndian)

Even lowly notepad can get THIS right!

Therein lies all your Unicode problems!
You naively omit the required identifiers when saving a UTF-16 file!!!!!!!!!!!!!!!!!

Select Configure | Preferences | Document Classes | <Class> | Write Unicode and UTF-8 BOM
or View | Document Properties | Preferences | Write Unicode and UTF-8 BOM.

It is not necessary to use oversized fonts, capitalised words and superfluous exclamation marks to get an answer.

Thanks for pointing out the solution to this problem - although it would seem more sensible for TextPad to default to saving files with a Byte-order Mark and having an option to relinquish it.
The issue for me is that you have a file that conforms to an accepted standard and TextPad overrides it by default rather than respecting the status quo. Fine if you are aware of the intricacies of the TextPad Configuration options, but otherwise problematical.

Apologies for the large text - my eyesight is poor!

Greetings. Some additional input on this...

I just spent a whole workday trying to figure out why files saved in TextPad could no longer be imported into a 3rd party GUI automation tool (Mercury QuickTest Pro--QTP). When QTP creates script files it includes the BOM. But preferring TextPad as an editor I was using it to make a large number of code changes. When I went to run the tests in QTP, the code was gone. Can you say, panic time?!! Of course the code wasn't gone--it was still in the file but the removal of the BOM meant QTP could no longer parse the file so it displayed an empty file. A little disconcerting!

I wasn't sure whose issue this was (TextPad or QTP) but after a day of research, I finally found this post. Thanks very much for the info.
One thought..... what about expanding this functionality to:
1 - by default, leave the source file as-is re: BOM
2 - if user changes default, there could be a 'force removal' or 'force add'

This seems like it would save folks the most trouble.
Thanks again..... I still think TextPad is a terrific product!!

If TextPad finds it there on open, it should write it on save. And the save-as dialog should have a checkbox for this.

Just my 2 cents.

The default behavior should definitely be to save the BOM if there was a BOM when the file was loaded. The ability to add/remove a BOM would be a nice feature, but the fact that TP blows the BOM away seems to me like a bug. (The work-around of always writing the BOM isn't that great either.)