Sat Jun 09 11:28:11 2012: Request 77525 was acted upon.
Transaction: Correspondence added by bulk88.
Queue: Win32-API
Subject: new release - version 0.69
Broken in: (no value)
Severity: Wishlist
Owner: COSIMO
Requestors: bul...@hotmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77525 >
Also, you want to look in 0.70,
https://rt.cpan.org/Public/Bug/Display.html?id=77728 I added a bunch of
things to the TODO file for future authors to consider that I
didn't/couldn't do. Most notably, I never added automatic UTF16 handling
which I thought of doing but ran into time and design problems. Rather
than "automatic" UTF16 handling, I decided some kind of generic perl sub
callback API for parameter un/packing would be better as described in
the TODO. The "friendly name" for raw function pointers is there so in
the future a un/pack callback will be passed that name. Also I gave
Win32::API::Type::Un/Pack the ::API object as the 1st parameter so
Math::Int64 flag can be checked today, and also that very advanced
un/packing designs can be implemented in the future, including per obj
or per caller package type callbacks.
Design problems were, what does "automatic" mean? whats the input CP?
System ANSI? Perl UTF8 (check SV flag)? a special $? some variable from
a perl pragma ? precomposed? and on output always convert to system
ANSI CP? or always convert to UTF8 flaged SV, or use lpUsedDefaultChar
to control whether output SV is UTF8 or legacy CP, or put utf8 in the SV
without ever turning on the UTF8 SV flag? What about "shorts", do they
stay numeric (0x41 not "A" not "\x41"), or do they become string like
("A" not 65) like the CHAR/char type? So thats why no automatic wide
handling was added.
The only "wide" feature I put in was that the buffer overflow sentinal
is wide compatible and will wide null terminate all string. I did use
Encode and there is a test and a api-test func to make sure binary
gibberish scalars with UTF16 in them correctly wind up in a C func
taking a Wide string and the C func validates the wide string. So yes,
today, with some work on your own, ::API has no limitations that prevent
you from using wide string apis.
