Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-11

no lazutils in 0.9.30.2

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hugues Moisy

Dear all,

I newly installed Lazarus on my PC (both Ubuntu and WinXP) and try to displat unicode strings (tibetan language) from Database in a Form. So I try to use the lazUtils components and AnsiToUTF8() as said in some mails, but can't find in both arborescences. In fact there is no lazarus\components\lazutils directory.

Would you tell what to do for being able to use this unit.

Thanks in advance.

Hugues MOISY

Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/

Reply by email

Felipe Monteiro de Carvalho
to Hugues Moisy

In Lazarus 0.9.30.2 or inferior you can use the UTF-8 routines from the unit LCLProc which is inside the LCL.

In 0.9.31+ they are all still there, but are now call LazUtils to do the real work, so code which uses LCLProc is compatible with a wide range of Lazarus versions.

Felipe Monteiro de Carvalho

Reply by email

Jesus Reyes
to Felipe Monteiro de Carvalho

--- El mar 15-nov-11, Felipe Monteiro de Carvalho escribi?:

Show quoted text 17 lines
De: Felipe Monteiro de Carvalho Asunto: Re: [Lazarus] no lazutils in 0.9.30.2 A: "Lazarus mailing list" Fecha: martes, 15 de noviembre de 2011, 7:08 In Lazarus 0.9.30.2 or inferior you can use the UTF-8 routines from the unit LCLProc which is inside the LCL. In 0.9.31+ they are all still there, but are now call LazUtils to do the real work, so code which uses LCLProc is compatible with a wide range of Lazarus versions. -- Felipe Monteiro de Carvalho

Something related to Lasutils, it seems that all windows snaphots that use 0.9.31 and fpc 2.5.1 are broken since r33116 or r32982, this problem it seems, not fixed by r33538 (bug report http://bugs.freepascal.org/view.php?id=20668).

The problem is that Wide2AnsiMove should convert from widestring to ansi, but the conversion is conditionated by PASWSTRING_SUPPORT_NONUTF8_ANSISTRING which is undefined by default, as result, in UTF8ToAnsi that does a UTF8->UTF16->UTF8->Ansi doesn't work as the last step is not done :D.

As result UTF8toAnsi does only UTF8->UTF16->UTF8, and this function is used by lazarus to convert a UTF8 path to ansi in order to save configuration files, in localized windows version like spanish where the config path is like: c:\Documents and Settings\user\Configuraci?n local\Datos de programa\lazarus it fails as it tries the UTF8 version of the path. As said, this occurs for 2.5.1 and 0.9.31.

BTW, what strange conversion UTF8->UTF16->UTF8->Ansi too many steps.

Jesus Reyes A.

Reply by email

Felipe Monteiro de Carvalho
to Jesus Reyes
Jesus Reyes wrote
Something related to Lasutils, it seems that all windows snaphots that use 0.9.31 and fpc 2.5.1 are broken since r33116 or r32982, this problem it seems, not fixed by r33538 (bug report http://bugs.freepascal.org/view.php?id=20668).

oh, I just inspected my IDE with "nm lazarus > lazarustable.txt" and the IDE is using paswstring.pas, but I inspected applications written using the LCL and they are not automatically linked against paswstring.

I just checked and I found the problem:
lazarus/packager/packagesystem.pas uses the unit LazUtils

So in rev 33553 I commited removing the LazUtils unit usage from this unit and I verified with nm that now paswstring is no longer added to the IDE.

It should be fixed now.

The problem is that Wide2AnsiMove should convert from widestring to ansi, but the conversion is conditionated by PASWSTRING_SUPPORT_NONUTF8_ANSISTRING which is undefined by default, as result, in UTF8ToAnsi that does a UTF8->UTF16->UTF8->Ansi doesn't work as the last step is not done :D.

paswstring was not written to be used in Windows, although it theorically can be. It was written to substitute cwstring in UNIXes, most importantly Android.

I added the ifdef to improve Android support. If you activate PASWSTRING_SUPPORT_NONUTF8_ANSISTRING then 1 MB will be added to your executable, and totally unnecessarely because in Android the system uses only UTF-8

paswstring is used inside the LCL when the define ANDROID is activated.

BTW, what strange conversion UTF8->UTF16->UTF8->Ansi too many steps.

The last step does not occur in the cases where paswstring was supposed to be used, like modern UNIXes.

Felipe Monteiro de Carvalho

Reply by email