[fpc-pascal] More help with unicode

Jonas Maebe jonas.maebe at elis.ugent.be
Sat Nov 10 16:56:28 CET 2007

On 10 Nov 2007, at 16:41, Felipe Monteiro de Carvalho wrote:

> On Nov 10, 2007 4:30 PM, Jonas Maebe <jonas.maebe at elis.ugent.be>  
> wrote:
>> You're making the same error which Marco pointed out earlier:
>> Utf8Decode returns a (reference counted) widestring, but you are not
>> assigning it to anything so it ends up in a (reusable) temp location.
>> As soon as the next temporary widestring has to be created, the
>> previous one is destroyed and the pwidechar will point to a random
>> memory block.
> Ummm, but there is nothing else on that function, so I don't see how
> can the temporary string be destroyed before I call SETTEXT,

You should never make assumptions about when compiler-managed types  
are destroyed when you don't hold an explicit reference to them  
anymore (it may happen immediately, or a long time in the future, and  
anywhere in between).

> unless
> SETTEXT expects that I give it a storage that is at all times
> available...
> procedure TWin32MemoStrings.SetText(TheText: PChar);
> begin
>    SendMessage(fHandle, WM_SETTEXT, 0, LPARAM(TheText));
> end;
> Which I currently converted into (but still doesn't work):
> procedure TWin32MemoStrings.SetText(TheText: PChar);
> var
>  AnsiBuffer: ansistring;
>  WideBuffer: widestring;
> begin
>  {$ifdef WindowsUnicodeSupport}
>    if UnicodeEnabledOS then
>    begin
>      WideBuffer := Utf8Decode(TheText);
>      SendMessage(fHandle, WM_SETTEXT, 0,  
> LPARAM(PWideChar(WideBuffer)));
>    end
>    else
>    begin
>      AnsiBuffer := Utf8ToAnsi(TheText);
>      SendMessage(fHandle, WM_SETTEXT, 0, LPARAM(PChar(AnsiBuffer)));
>    end;
>  {$else}
>    SendMessage(fHandle, WM_SETTEXT, 0, LPARAM(TheText));
>  {$endif}
> end;
> Alternatively I moved AnsiBuffer and WideBuffer to the class
> declaration, so they are always available, which also didn't solve the
> problem of showing wrong characters.
> It shows the string ééé as if it was Ã(c)Ã(c)Ã(c)
> Which is what I would expect if I use ansi routines to show a utf-8  
> string.

The above code looks correct as far as managing the data is concerned.  
I don't know anything about the win32 api though, so I can't help  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20071110/c4f44a3d/attachment.html>

More information about the fpc-pascal mailing list