Re: [twsocket] A better Unicode port of the POP3 client
Hi, Zvonko Tesic found a problem in last version. It did not make the C++ Builder happy since new private property getter GetUserName caused a name conflict with Win32 API functions GetUserNameA and GetUserNameW. This is now fixed in OverbyteIcsPop3Prot.pas. You may want to download the new files: http://www.duodata.de/misc/delphi/ics/OverbyteIcsPop3Prot.zip Or simply add two lines right after the uses section in OverbyteIcsPop3Prot.pas: (*$HPPEMIT '#pragma alias @overbyteicspop3p...@tcustompop3cli@GetUserNameA$qqrv=@overbyteicspop3p...@tcustompop3cli@GetUserName$qqrv' *) (*$HPPEMIT '#pragma alias @overbyteicspop3p...@tcustompop3cli@GetUserNameW$qqrv=@overbyteicspop3p...@tcustompop3cli@GetUserName$qqrv' *) -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] A better Unicode port of the POP3 client
Arno,
I just wanted to notify you you have a slight error with this line in this
updated port of pop3:
FLocalAddr := ICS_ANY_HOST_V4;
ICS_ANY_HOST_V4 is undefined with the current ics7 package. probably it is
defined for you locally but not with the ics7 downloadable package.
when I replace with older variant:
FLocalAddr := '0.0.0.0'; {bb}
it works just fine
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] A better Unicode port of the POP3 client
Zvonko Tesic wrote:
Arno,
I just wanted to notify you you have a slight error with this line in
this updated port of pop3:
FLocalAddr := ICS_ANY_HOST_V4;
ICS_ANY_HOST_V4 is undefined with the current ics7 package. probably
it is defined for you locally but not with the ics7 downloadable
package.
when I replace with older variant:
FLocalAddr := '0.0.0.0'; {bb}
Thanks, corrected and uploaded. ICS_ANY_HOST_V4 is a const defined as
'0.0.0.0' in the IPv6 branch.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] A better Unicode port of the POP3 client
Hi, I uploaded a better Unicode port of TPop3Cli here: http://www.duodata.de/misc/delphi/ics/OverbyteIcsPop3Prot.zip Thanks for making a quick fix, I will surely use it and probably a few other people here as well. But I'm more for a permanent solution so I'll keep an eye on this. I've been researching a bit and seems that using AnsiChar and AnsiString types to store binary data are safe they only have codepage associated with them so only conversions may be issue but apart from that they should behave binary safe as before in earlier versions of Delphi/C++. As long as you assign one AnsiString with the same codepage (like system default one, even if it is Japanese locale) there should be no conversions. I'm not sure though what would happen if two AnsiStrings were in different codepages, then probably some conversions may occur but haven't tried that. But of course TBytes is better for this purpose although it doesn't have so many useful methods in it for manipulating the data like AnsiString has... -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] A better Unicode port of the POP3 client
Zvone wrote: Hi, I uploaded a better Unicode port of TPop3Cli here: http://www.duodata.de/misc/delphi/ics/OverbyteIcsPop3Prot.zip Thanks for making a quick fix, I will surely use it and probably a few other people here as well. But I'm more for a permanent solution so I'll keep an eye on this. I did not update the source repository since this patch breaks existing RDS 2009+ apps. It's probably too late to go into v7, though one could argue that it fixes a bug and also improves performance? I've been researching a bit and seems that using AnsiChar and AnsiString types to store binary data are safe they only have codepage associated with them so only conversions may be issue but apart from that they should behave binary safe as before in earlier versions of Delphi/C++. As long as you assign one AnsiString with the same codepage (like system default one, even if it is Japanese locale) there should be no conversions. That's correct. Using AnsiString for binary data however was dangerous in older versions too. Whenever the content was interpreted as texual content by the RTL/VCL. I'm not sure though what would happen if two AnsiStrings were in different codepages, then probably some conversions may occur but haven't tried that. It might be different in C++Builder, in Delphi for example, any string passed to procedure Foo(S: UTF8String) will be converted to UTF8String implicitly if its codepage wasn't CP_UTF8. In order to prevent those implicit conversions of ansi strings you have to use RawByteString as the parameter type. Passing a UnicodeString to a parameter of type RawByteString converts it to the default AnsiString (with current system ansi codepage). -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
