Hi,
On 02/05/2013 10:34, Johan Vromans wrote:
The question is: do we consider wxWidgets to be 'external world'. That
answer is most likely 'yes'. But more important: do we consider wxPerl
to be 'external world'? I'd say 'no'. Therefore, what I'd expect to pass
to a wxPerl routine is a string in Perl's internal encoding. The wxPerl
wrapper should take care of encoding the string into whatever encoding
wxWidgets requires.
Compare this to {some, several, many, all} DBD drivers that handle the
internal/UTF-8 conversions transparently.
Alternatively, it's an (almost) equally good decision to require all
strings passed to a wxPerl routine to be encoded in UTF-8. For a program
that is correctly equipped to handle multibyte encoded strings it will
not make a difference.
-- Johan
I'd agree with that. For Wx 0.9922 I've changed the conversion to
wxString so that it always uses a UTF-8 conversion.
At least I'm assuming that's what SvPVutf8_nolen does. It seems to, and
the docs say it does. Contrary advice from perlapi utf8 gurus most
welcome. Essentially I want
char * buffer = SomePerlApi( SV );
where &buffer is the address at the start of a stream of UTF-8 octets.
I think SvPVutf8_nolen( SV ) does the job.
In testing this change though, I had to go back to Perl 5.8.9 to
contrive a case where it made any difference. Even there, it might be an
issue with older module versions - but given it was Perl 5.8.9 I was not
inclined to investigate further.
So I'd say from testing that wxPerl already handled things transparently
and continues to do so.
In short, I think that
my $string = decode( $someencoding, $externaldata );
or
my $string = $some_other_Perl_string;
# ... optionally some string operations on $string
$wxobject->SetValue( $string );
Should always work and if it doesn't it is a probably a bug in wxPerl.
This is regardless of utf8 flags etc etc. It should just work from an
end user perspective.
If someone demonstrates an instance where the above doesn't work, I'll
endeavour to get it fixed.
Cheers
Mark
