On 3/2/2010 21:13, Reece Dunn wrote:
On 1 March 2010 17:39, Nikolay Sivov<[email protected]> 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
