Hello,

I would like to use Lazarus without Unicode support on Windows, as it was possible up to version 0.9.24. I took a recent 0.9.27 snapshot and compiled it with -dDisableWindowsUnicodeSupport. My "old" projects seem work well, but the editor does not show the german umlauts correct. I changed File Settings.../Encodings but this did not help.

For sure, I belong to a minority which has no need for Unicode. For me, it would be great to have Unicode disabled in Lazarus. So what is the intention behind "DisableWindowsUnicodeSupport" in theses days? If it should work, I would make a bug report.

Regards, Bernd.

This define is placed in the code temporary. I suppose it will gone with time.

What problems do you have with unicode version? IOW, why do you need ansi version?

Best regards,
Paul Ishenin.

it is the fear, that I could break my working code. This is the main reason, why I am still on 0.9.24. From what I have read in this list, Unicode handling seems to be very complex and to be honest, I did not take the time to look into this subject, because I had no need to do so.

Some of my applications interact with embedded systems which use plain short strings for speed reasons. If time does not matter, I use Ansi strings. Putting such a string in a TMemo for example would cause trouble in Lazarus 0.9.26+. I know, I have to use AnsiToUTF8 now. But I could miss something.

So, if there would be an Ansi Lazarus version, I could leave my code as it is. May be, that I try to use Unicode Lazarus for new projects.

Thanks anyway for your effort.

Regards, Bernd.

My response can be seen as an addition to Paul's.

As far as I am concerned, the dDisableWindowsUnicodeSupport does not need to be removed. OTOH working with -dDisableWindowsUnicodeSupport has no priority for me. If the Lazarus community does the testing and supplies patches, I don't mind committing them (much like I said about the fixes_0_9_26 branch, no effort form me, but willing to support the efforts of others).

I am willing to accept bug reports, if it turns out that a regression was caused by on of my commits, i.e. it worked before with DisableWindowsUnicodeSupport, and after it didn't.

Having said that, I fear that some incompatibilities remain, because the LCL (not the win32 interface) insert conversion to UTF8 when using RTL functions in for example the TFileListBox.

Finding a solution for such issue is not a priority for me, but patches will be reviewed and accepted if ok.

Vincent

As for Synedit:
1)
There may be code elsewhere, that detects the filetype while loading the file => in this case it should convert it to utf8.

2) If one doesn't happen. Try the following. (I have not tested it, but it *may* do the trick)

open C:\lazarus_latest\components\synedit\syntextdrawer.pp

line 889 function TheTextDrawer.GetUseUTF8: boolean;
and make the function to always return "False"

I made the change and recompiled Lazarus with
-dDisableWindowsUnicodeSupport but the editor still does not show the umlauts correct, when the file is opened. When I type the umlauts, they are displayed correct now. But reopening the saved project leads to wrong characters.

Regards, Bernd.

If I were you, I would give it a go at converting the applications to Unicode. Only places which connect with the LCL, such as putting text in a TMemo need change, and even those don't need change if you only use ASCII characters. All non-textual and non-LCL code remains unaffected.

2009/5/8 Felipe Monteiro de Carvalho :

I agree. It took me just 4 hours to clean up my code and put some "Utf8toAnsi" and "AnsitoUtf8" here and there.

Gustavo