On 3/2/2010 21:13, Reece Dunn wrote:
On 1 March 2010 17:39, Nikolay Sivovbunglehead@gmail.com wrote:
On 3/1/2010 20:01, Paul Vriens wrote:
On 03/01/2010 12:56 AM, Nikolay Sivov wrote:
Implement SHFormatDateTimeA/SHFormatDateTimeW with tests.
Spotted in logs while testing IE6.
Hi Nikolay,
This one introduces failures on what appears Vista+ :
http://test.winehq.org/data/tests/shlwapi:ordinal.html
Could you have a look?
Hi, Paul.
It looks like it adds some special characters on new versions. I'll take a look. It could be LTR markers (I never saw them before though, only read about). Also I suspect problems with formatting, but for now we could wait for reports.
Isn't it locale dependent? That is, you are passing LOCALE_USER_DEFAULT, so it will use the settings from the "Regional and Language Settings" on Windows (e.g. Japanese date format -- "2010年3月2日", or user-specified).
Yes, it's dependent of course, that's why I'm calling GetDateFormat with that locale specifier. And I expect whatever defined in locale data, available with -A call as well. For example I don't think Japanese fails to get -A format even with specific characters defined, that's what WideCharToMultiByte is for.
Specifying an English LCID should work, but may fail if the user has entered a custom format containing special characters, so could still fail, It may also fail if English is not available.
I don't want to silence test failures actually, I'm going to run additional test on failing boxes with testbot soon.
Also, it might be useful to change the code page to a UTF-8 code page so that the SHFormatDateTimeA calls return UTF-8 strings and as a result, we can see what the characters are (if this is possible).
SHFormatDateTimeA doesn't return UTF-8 of course. I suspect special formatting characters.
- Reece