Ok, thanks for the code.

I will try it. I know that some special chars from romanian language are
displayed correctly because they are used in ISO-8859-1 also.

For example, â and î are displayed correctly, but ş, ţ and ă are not.

I will try to see if your code helps to show them right.

Thanks.

Octavian

----- Original Message ----- 
From: "Glenn Linderman" <[EMAIL PROTECTED]>
To: "Santeri Paavolainen" <[EMAIL PROTECTED]>
Cc: <perl-win32-gui-users@lists.sourceforge.net>; "Octavian Rasnita"
<[EMAIL PROTECTED]>
Sent: Tuesday, November 28, 2006 10:08 AM
Subject: Re: [perl-win32-gui-users] charset


> On approximately 11/27/2006 11:25 PM, came the following characters from
> the keyboard of Santeri Paavolainen:
> > Hi,
> >
> > I have used Win32::API and Encode to accomplish this directly via
> > SetWindowTextW function which takes a UTF-16LE string argument:
> >
> >     use Win32::API;
> >     use Encode;
> >
> >     our $SetWindowTextW_fn = undef;
> >     sub text {
> >       my ($control, $text) = @_;
> >       if (not $SetWindowTextW_fn) {
> >         $SetWindowTextW_fn = Win32::API->new("user32", "SetWindowTextW",
> >     "NP", "N");
> >         die unless $SetWindowTextW_fn;
> >       }
> >       $SetWindowTextW_fn->Call($control->{-handle}, t2w($text));
> >     }
> >
> >     # t2w - convert arbitrary string (may be unicode or not) to UTF-16LE
> >     # encoding. Windows uses UTF-16LE as its native Unicode encoding
(the
> >     # "W" version of functions).
> >     sub t2w {
> >       my ($text) = @_;
> >       return encode("UTF-16LE", $text . "\x00");
> >     }
> >
> > Since the "encode" function follows the normal Perl unicode'ness rules
> > it will work correctly if you give it an unicode string (as long as it
> > has been decoded to perl's internal format, of course). For example,
> > text($label, "\x{0032}\x{2208}\x{007b}\x{0032}\x{007d}") should work.
> > Ought. Might. :-)
> >
> > *Note*: I have not extensively tested whether this works for all unicode
> > codepoints - it was a hack I needed to get some characters shown
> > correctly and after that was accomplished I have never looked at the
> > code since. Also, this worked with 1.03. I have not tried it with more
> > recent Win32::GUI versions.
> >
> > Hope this helps,
> >
> > Santeri Paavolainen
>
>
> Interesting!  And thanks for the encouragement that such a mixture might
> work...
>
> So I modified Dan's code as below, and it almost works...
>
> I got a blank window, until I initialized the label with a non-empty
> string value... probably due to length calculations somewhere.
>
> Unfortunately, only the first accented character retains it accent...
> the other 3 do not.  The other three all seem to be characters used only
> in Romanian (among language character sets I am somewhat familiar with).
>   I wouldn't think that UTF-8 to UTF-16LE translation should affect
> that, so it must be something else... Some hex dumps convince me that
> the encode is working properly, so that is good.  But the text is still
> not properly displayed, even though it is clearly being set by the 'W'
> form of the API call.
>
> So perhaps the code page for the screen overrides the best efforts of
> the programmer to display the right stuff?
>
>
> #! perl -w
> use strict;
> use Win32::GUI ();
> use Win32::API ();
> use utf8;  # enable Perl to parse UTF-8 from this file
> use Encode;
>
> # t2w - convert arbitrary string (may be unicode or not) to UTF-16LE
> # encoding. Windows uses UTF-16LE as its native Unicode encoding (the
> # "W" version of functions).
> sub t2w {
>    my ($text) = @_;
>    return encode("UTF-16LE", $text . "\x00");
> }
>
> our $SetWindowTextW_fn = undef;
> sub text {
>    my ($control, $text) = @_;
>    if (not $SetWindowTextW_fn) {
>      $SetWindowTextW_fn = Win32::API->new("user32", "SetWindowTextW",
> "NP", "N");
>      die unless $SetWindowTextW_fn;
>    }
>    $SetWindowTextW_fn->Call($control->{-handle}, t2w($text));
> }
>
>
> my $string = 'Râşniţă';
> print $string;  # this should warn about "Wide character in print",
> # confirming that $string was correctly parsed from UTF-8 into Perl's
> # internal representation
>
> my $main = Win32::GUI::Window->new(
>      -name => 'Main',
>      -size => [400, 300],
> );
>
> # The Label will inherit $win_main's font
> my $label = $main->AddLabel(
>      -text => 'this is a temp string',
> );
>
>
> text($label, $string);
>
> $main->Show;
> Win32::GUI::Dialog();
>
>
> >
> > Glenn Linderman wrote:
> >> On approximately 11/27/2006 10:34 PM, came the following characters
from
> >> the keyboard of Octavian Rasnita:
> >>
> >>>> I can't actually help you here, off the top of my head, but it is an
> >>>> area that I am interested in.  Have you noted Dan Dascalescu's post
on
> >>>>
> >>>> Date: Sat, 18 Nov 2006 18:44:57 -0800
> >>>>
> >>> Hi,
> >>>
> >>> Yes, I have also "talked" on private with Dan. He told me that he
tried to
> >>> initialize some fonts, and to specify the charset for them. He tried
very
> >>> many charsets, but the result was always the same: the program was
using the
> >>> default ISO-8859-1.
> >>>
> >>> It is too bad if Win32::GUI can use only a single charset because it
is the
> >>> most accessible GUI library for screen readers, and I will need to try
using
> >>> another one like WX...
> >>>
> >>> Thanks.
> >>>
> >>> Teddy
> >>>
> >>
> >> OK.  I was under the impression that Dan had had some success with the
> >> code he posted.  I guess I misunderstood... by suggesting adding
> >> documentation links to the Win32::GUI documentation, I thought he'd
> >> found some clever way to bypass the limitations of Win32::GUI... which
> >> has been known not to support Unicode for some time (other than in
> >> RichEdit controls)... Unicode is on Robert's list, I think.
> >>
> >> Win32::GUI does use the "A" version of the Win32 APIs... so given that,
> >> I would expect (but have never tested) that any single-byte code page
> >> could be used.  I think I recall seeing posts from people that have
> >> gotten various code pages to work, but I'm not sure I could find them
again.
>
> -- 
> Glenn -- http://nevcal.com/
> ===========================
> A protocol is complete when there is nothing left to remove.
> -- Stuart Cheshire, Apple Computer, regarding Zero Configuration
Networking


Reply via email to