Posted 9 years ago by RafaelLVX
Version: 2.4.15
Avatar

Hi.

Just found Code Writer on the brazillian Gizmodo "apps of the week" post and I was impressed with most of what I saw. But in order to use this day-to-day, like many devs, I'm gonna need control of encoding. I noted this has been reported here before, and in most cases it appears people gave up trying instead of finding a solution. I tried a lot of things, and I even understood now how this works and how I can workaround the problems, but as it is it's far too dangerous to get encoding wrong by mistake. See below.

Situation 1: app configured to auto-detect encoding, opened html file with ISO-8859-1 encoding

What it does: does not auto-detect ISO-8859-1, which is fine by me, as long as I could manually select it. Opening the encoding menu and changing it to Latin 1 or Western European does nothing, all special characters stay invisible. Saving the file like this obviously discards the special characters, which is a disaster.

 

Situation 2: app locked for western european encoding, opened both an ANSI-encoded and an UTF8-encoded html files

What it does: this is interesting. It opens both files just fine, displays both files' special characters correctly. Problem is, although now the app is compatible with ISO-8859-1, it saves UTF files into western european encoding, thus potentially breaking all UTF8 files I try to edit.

 

Situation 3: app locked for UTF8 encoding, opened both an ANSI-encoded and an UTF8-encoded html files

What it does: of course now the ANSI file had trouble displaying special characters and loses them upon saving. UTF8 file displays and saves correctly.

 

You see, with the right pre-configuration it can work, but I'll have to manually change the standard config before opening each and every file. This is because I think you're doing this wrong.

Displaying, converting and saving files into a certain encoding are three different things, but here it's done with the same menu dropdown: it could be fine if it did something when you touched the dropdown menu, but it doesn't. When you open a file with the right encoding it just works, but opening with the wrong encoding only works for UTF8, and saving with the wrong encoding always happens freely with no warning. Selecting the right encoding for the file with the wrong encoding does nothing.

Note how this is done with Notepad++. You open a file with the wrong encoding (because Notepad++ can't detect correctly either), it displays wrong. You change it to display with the right encoding, it starts displaying right. You tell it to convert to whatever encoding you want, it does that and starts displaying in the new encoding. THEN you save it if you want, or convert back if you want, or leave it if you want.

 

Phew. That's about it. I think people who need to view and edit files with different encodings won't be able to while this is done as it is.

 

By all means let me know if I got it wrong so I can try again, I'm willing to test it further.

Comments (2)

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hello,

It seems like an ideal solution would be that once a file was opened, the Document Properties pane's (F4) Character Encoding drop-down would live convert the visible text.  Then you could choose to save or discard the changes.  Saving a document would save it using the Character Encoding in that drop-down, which is what happens now.  Does that sound right?

The missing piece is the ability to convert an already opened file.  We did some tests and once a file's contents has been loaded into a C# string using an incorrect file encoding, it seems that it's impossible to get the bytes back to do an encoding conversion to a new target encoding.  We unfortunately don't track document text data by bytes, but rather by C# strings.

Thus I'm not sure what the best solution is here.  If you change the character encoding in that dropdown after a file has been opened, we could prompt for whether you'd like to reload it from the file.  Assuming you haven't made changes, that might work well.  What should happen if there are pending unsaved changes?

Do you have any better suggestions?


Actipro Software Support

Posted 9 years ago by RafaelLVX
Avatar

It seems like an ideal solution would be that once a file was opened, the Document Properties pane's (F4) Character Encoding drop-down would live convert the visible text.

Yes, that is useful, because it's usually impossible for text editor apps to detect the correct encoding (no app that I know does that 100% right) and you only figure the app got it wrong when you note the wrong characters, midway through.

Then you could choose to save or discard the changes. Saving a document would save it using the Character Encoding in that drop-down, which is what happens now.

Yes, if the human ever notes he's using the wrong encoding, after he chooses the right one from the dropdown and the app starts to display special characters correctly, app already has the right encoding selected when human clicks on "save". App would then save the right encoding from the dropdown, which it already does.

The missing piece is the ability to convert an already opened file. We did some tests and once a file's contents has been loaded into a C# string using an incorrect file encoding, it seems that it's impossible to get the bytes back to do an encoding conversion to a new target encoding. We unfortunately don't track document text data by bytes, but rather by C# strings.

That is unfortunate, but makes some sense. I suppose that's a limitation that could change in the future? At the very least your suggestion below makes it manageable for the dev that's aware of the problem.

Thus I'm not sure what the best solution is here. If you change the character encoding in that dropdown after a file has been opened, we could prompt for whether you'd like to reload it from the file. Assuming you haven't made changes, that might work well. What should happen if there are pending unsaved changes?

While that could mean having to start over the work on a given file, having the ability to start displaying the right characters without having to re-open each and every file to test for each encoding possible would make all the difference in the world, it's the minimum needed to work with different encodings. As it is, the only way to work is to pre-configure the app to get the right encoding before opening each file, back and forth each time.

What I'd do in that situation (that it prompts me unsaved changes would be lost) would be some good old copy and paste of the whole text into a clean document before reverting to the old file, then comparing the differences to re-apply the work I just did. It would be useful to have a document comparison tool for that situation, but rather complex and messy, not worth the effort.

On top of the document properties pane (F4) there's refresh button, right? On my tests I spammed that button thinking it would make the encoding refresh after I changed it from the dropdown menu, but obviously that's not what it does. What does it do? (I'm not suggesting it should do what I just said, I'm really just curious now).

The latest build of this product (v4.2.42) was released 3 years ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.