[comctl32/tests] Fix some test failures

[Paul Vriens]

On 10/01/2009 02:03 PM, Nikolay Sivov wrote:
> Paul Vriens wrote:
>> On 10/01/2009 01:32 PM, Nikolay Sivov wrote:
>>> Paul Vriens wrote:
>>>> On 10/01/2009 12:29 PM, Paul Vriens wrote:
>>>>> Hi,
>>>>>
>>>>> Instead of checking fixed points in the title we now check for the
>>>>> order
>>>>> of items only.
>>>>>
>>>>> I didn't cater for locale differences on Windows (as I don't have a
>>>>> way
>>>>> to test), so I'm going to rely on test.winehq.org after this patch has
>>>>> been applied (if, of course).
>>>>>
>>>>> The test could be easily extended if we know for a fact that items
>>>>> should be at a fixed place (or by calculating text width, button width
>>>>> an such).
>>>>>
>>>>> Changelog
>>>>> Fix some test failures
>>>>>
>>>>
>>>> FWIW, changing the regional settings on a Windows box does change the
>>>> title of the calendar. Setting it to Portuguese shows that the name of
>>>> the month is longer than expected and hence the hittests don't work as
>>>> it was before.
>>>>
>>>> This patch also succeeds on the Portuguese settings (tested on W2K3).
>>>>
>>> So, back to previous question, after a brief search for this string
>>> 'LOCALE_SYEARMONTH "yyyy' I found some locales that use that.
>>> Now the question is does this control respect this locale parameter.
>>> I'll to run native comctl32 for one of such locales today later, or will
>>> force this string for default ENU. After that it'll be clear what to do
>>> with our monthcal.
>>
>> If I set the regional settings to Lithuanian I can see the title as
>> "2007 m. balandis" which corresponds to LOCALE_SYEARMONTH in the nls
>> file.
>>
>> The first and last character show up 'underneath' the prev/next
>> buttons and the control is smaller than in US-English. This is because
>> the day acronyms are only 2 characters.
> You're testing on Windows system?

Yes, this was on Windows XP.

>
> In git abbreviated day names use locale data already, so it should be
> smaller in Wine too.
>>
>> So the patch is not correct as it doesn't cover all cases (yet).
>>
> It could be fixed with GetLocaleInfo() but it complicates test of course.

Well, yes. Are you going to go further with this or should I "perfect" 
at least the tests?

-- 
Cheers,

Paul.