Damir Šimunović

Unfortunately, I already tried setting FoxLangId_EEurope_1250 earlier and that doesn't help. It's not a code page problem, it's a sorting problem. TDbf correctly recognizes code page 1250 and correctly writes and reads specific Croatian characters (which, by the way, are not the same as in the Czech language), but does not know how to sort them.

Regards, Paul. Is there any news concerning the problem with string sorting with locale 1050?

All right, Paul, thanks, I appreciate that.

This happens when a Form is created even though the TDbf component was not created at all. Function ConstructLangId calls function FindLangId twice: first with CodePage, then without. In first run: function FindLangId CodePage = 1250 Info2 = 1050 Info2Table = $66D3DC IsFoxPro = false after loop for I := 0 to $FF - Region = 2 - DbfRes = 0 - FoxRes = 0 finally: Result = 0 In second run result is the same. Obviously function can't find LangId with Locale = 1050.

GetACP() returns ANSI codepage 1250 as it schould be. When I create and open dbf, both with the old and with the new TDbf, TDbf.CodePage returns 1250. Dbf-dbffile.pas contains the property DbfGlobals.DefaultCreateLangId. This reads the FDefaultCreateLangId that should be formed in TDbfGlobals.Create, but is not formed then but in the SetDefaultCreateCodePage procedure. It is formed by the CostructLangId function from the dbf_lang unit. However, at the moment I do not see what and when is calling...

with exe

without exe

Regards, Paul, attached is a ZIP file with a program that creates a table and fills it with a series of strings that use specific characters of my language. Such a table is also proba4.dbf with indexes in the proba4.mdx file. You can create a new table and load it by clicking on bFillData with the same data. My Windows is set to Croatian language (HRV code). GetUserDefaultLCID() returns 1050. When creating dbf, codepage is automatically set to 1250. A strange code DB0 is written under the language,...