Warning: Editor kills source file, if invalid characters

[Fred]

If the editor encounters a character which it regards as invalid for the file font encoding, it saves the file with 0 bytes.
Even if it is in a comment.
When you try to build it, the linker will complain, because the file has been saved automatically and is empty.
But in the editor window the text is still present...
Hopefully you have a recent backup.
I had this problem two times now when copying code with string constants from other source files.

Regards,
Fred

[eranif]

If you got a problematic character, codelite should prompt you if it fails to save the file (and it should not save it)
Quickly looking at the code, I see that there is a check to make sure that the conversion actually succeeds before attempting to save the file.

I believe that it is a bug in wxWidgets, but in any case maybe adding another check to make sure that the file length is greater than zero will help.

Hopefully you have a recent backup.

You are right having a backup is always a good idea ( I never work without source control)
I suggest that you work with svn / or git locally (git is better, since you dont need to connect to a remote server)

In addition, did you try setting another locale? ( try using ISO8859-1, or UTF8)

Make sure you open a bug report with high priority
Eran

[Fred]

Thank you for your quick reply.

If you got a problematic character, codelite should prompt you if it fails to save the file (and it should not save it)
Quickly looking at the code, I see that there is a check to make sure that the conversion actually succeeds before attempting to save the file.

There is no warning or message here, it silently overwrites the source file.
If you close the editor tab then, your code is lost.

I believe that it is a bug in wxWidgets, but in any case maybe adding another check to make sure that the file length is greater than zero will help.

Yes, I think so, too.

Hopefully you have a recent backup.

You are right having a backup is always a good idea ( I never work without source control)
I suggest that you work with svn / or git locally (git is better, since you dont need to connect to a remote server)

I fully agree.

In addition, did you try setting another locale? ( try using ISO8859-1, or UTF8)

I am working with global editor prefererences / file font encoding = ISO-8859-1.
When using the Windows API you cannot use UTF-8, because the string literals in your code would be passed UTF-8 coded to the API functions, which expect ANSI rsp. UCS-2 LE.

Make sure you open a bug report with high priority
Eran

I'll do so and give a sample.

Regards,
Fred

[eranif]

When using the Windows API you cannot use UTF-8, because the string literals in your code would be passed UTF-8 coded to the API functions, which expect ANSI rsp. UCS-2 LE.

Changing the global editor preferences encoding only affects how codelite converts the text before saving it.
The strings will be passed as ASCII unless you set L"wide string"

Eran

[Fred]

Thank you for your reply.

When using the Windows API you cannot use UTF-8, because the string literals in your code would be passed UTF-8 coded to the API functions, which expect ANSI rsp. UCS-2 LE.

Changing the global editor preferences encoding only affects how codelite converts the text before saving it.
The strings will be passed as ASCII unless you set L"wide string"
Eran

No, here it is passed to the Win API function as UTF-8 bytes.
With editor file font encoding set to UTF-8 this code

Code: Select all

MessageBoxA(hWindow, "Grüße!", "Test", MB_OK);

the message box text is Grüße!

If the encoding is set to ISO-8859-1, the output is correct.

Regards,
Fred

[Fred]

Thank you for fixing this problem so soon.
CodeLite really is one of the few well-maintained projects!

The problem was not only with German Umlauts, but also with all UTF source code files which start with a UTF-8 'BOM'.
Looks like the wxWidgets editor cannot process this correctly

The other item, that I have to use ISO-8859-1 to have correct string literals for Win API calls, is not a problem for me.
Imo it is as expected.
For Win Unicode APIs widechars > 127 in wide literals must be escaped: const wchar_t* wStr = L"Gr\u00FC\u00DFe";

Regards,
Fred