I use also the autoconvert to DOS feature all the time and also the Save file as input format option.
With this settings, a Unix or MAC file is automatically converted to DOS for editing only, but always saved as Unix or MAC according to the format detected during open.
If "Save file as input format" is not checked, Unix or MAC files are converted automatically to DOS for editing AND are saved as DOS.
But when you use a conversation manually or within a macro, this automatic file format handlings are disabled and the file is save in the new format indepent of the "Save file as input format", although it is still handled in the buffers of UltraEdit as DOS format.
So a manual conversation always forces UltraEdit to save the file in this format until it is closed.
What is still confusing you:
a) You converted the file to Unix.
b) You saved the file - it's really stored in Unix.
c) You close the file.
d) You open the file - the LFs are automatically converted to CRLF in the buffers.
e) You look into the file in hex mode and see 0D 0A ????
Yes, you see 0D 0A, because you see the file buffer content and not what is really saved on your harddisk.
To see in hex, what is really stored on your harddisk open the file with another hex viewer tool or after c) turn off the autoconvert to DOS feature and then do d) and e).
So you maybe ask yourself: Why should a Unix or MAC file be converted to a DOS file just for editing and confusing me if a look into it in hex mode?
It makes sense to convert all line ending variations to DOS just for editing when you copy some lines via clipboard to other programs, which can only work with DOS line terminations.
Older versions of UltraEdit are also not able to automatically convert a Unix formated clipboard content automatically to current file format on paste from clipboard. Since v11.10 there exists an option in UltraEdit for conversation of line endings to current file format on paste from clipboard. Since v11.10b this function also works for Win9x.
Best regards from Austria