On 16/9/2011 14:24, Luiz Americo Pereira Camara wrote:
On 16/9/2011 14:03, Luiz Americo Pereira Camara wrote:
On 16/9/2011 09:36, Marco van de Voort wrote:
he UTF8 -> UTF16 conversion is done
All the routines you name (fileexists, filegetattr etc) will become
rawbytestring and accept both utf8 and utf16, and then only in the
implementation figure out if conversion is necessary. (to the
encoding of
the OS)
Better.
I took a look at the Delphi An Unicode document by Marco Cantu and a
get doubt about the implementation with RawByteString:
Assume the implementation under windows of FileGetAttr:
[..]
with RawByteString (need the conversion - but how ?????):
Nevermind i found the answer at
http://www.micro-isv.asia/2008/08/using-rawbytestring-effectively/
"Then |ShowCodePage(A)| will display 1252, and |ShowCodePage(F)| will
display 65001. The StringCodePage function gets the code page
information stored in the string at runtime, not the declared code page,
which is 65535 for RawByteString. This means that StringCodePage is only
meaningful when calling it on a string variable that actually holds a
string. If it doesn’t hold a string, StringCodePage cannot retrieve the
code page, and it will always return the default code page."
The codepage of a RawByteString at runtime will keep the previous
CodePage (65001 for UTF8, 1200 for UTF16) as opposed to change to the
RawbyteString CodePage (65535) as a though previously
So the implementation would be:
function FileGetAttr(const FileName: RawByteString): Longint;
begin
SetCodePage(FileName, 1200, True);
Result:=Integer(Windows.GetFileAttributesW(PWideChar(FileName)));
end;
This way the version using UnicodeString parameter would have the
benefit of being less verbose and use the possible optimizations of the
implicit encoding conversion.
Luiz
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
