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).
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.
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.
So the patch is not correct as it doesn't cover all cases (yet).
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?
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.
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?
Paul Vriens wrote:
On 10/01/2009 02:03 PM, Nikolay Sivov wrote:
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.
Ok, I'll try to fix it someday.
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?
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
On 10/01/2009 02:58 PM, Nikolay Sivov wrote:
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
Well I need to test for all possible occurrences of month and year. So something like:
/* Get the format of the title */ len = GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, NULL, 0); yearmonth = HeapAlloc(GetProcessHeap(), 0, len); GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, yearmonth, len); /* Find out the order */ year = strstr(yearmonth, "y"); month = strstr(yearmonth, "M");
if (month < year) trace("Month before year\n"); else trace("Year before month\n"); HeapFree(GetProcessHeap(), 0, yearmonth);
The 3 tests I removed with the first patch can be removed safely as all should be tested in the loop.
Now I need to change the way we test to cope with: - order of year/month - text right after the prev button or right before the next button
On 10/01/2009 03:12 PM, Paul Vriens wrote:
On 10/01/2009 02:58 PM, Nikolay Sivov wrote:
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
Well I need to test for all possible occurrences of month and year. So something like:
/* Get the format of the title */ len = GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, NULL, 0); yearmonth = HeapAlloc(GetProcessHeap(), 0, len); GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, yearmonth, len); /* Find out the order */ year = strstr(yearmonth, "y"); month = strstr(yearmonth, "M");
if (month < year) trace("Month before year\n"); else trace("Year before month\n"); HeapFree(GetProcessHeap(), 0, yearmonth);
The 3 tests I removed with the first patch can be removed safely as all should be tested in the loop.
Now I need to change the way we test to cope with:
- order of year/month
- text right after the prev button or right before the next button
Oh and it's also possible to not have any room between year and month:
SetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, "yyyyMMMM");
Paul Vriens wrote:
On 10/01/2009 03:12 PM, Paul Vriens wrote:
On 10/01/2009 02:58 PM, Nikolay Sivov wrote:
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
Well I need to test for all possible occurrences of month and year. So something like:
/* Get the format of the title */ len = GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, NULL, 0); yearmonth = HeapAlloc(GetProcessHeap(), 0, len); GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, yearmonth, len); /* Find out the order */ year = strstr(yearmonth, "y"); month = strstr(yearmonth, "M");
if (month < year) trace("Month before year\n"); else trace("Year before month\n"); HeapFree(GetProcessHeap(), 0, yearmonth);
The 3 tests I removed with the first patch can be removed safely as all should be tested in the loop.
Now I need to change the way we test to cope with:
- order of year/month
- text right after the prev button or right before the next button
Oh and it's also possible to not have any room between year and month:
SetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, "yyyyMMMM");
Yes, but this is a system wide setting, I don't know is it ok to do such things in tests.
Paul Vriens wrote:
On 10/01/2009 02:58 PM, Nikolay Sivov wrote:
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
Well I need to test for all possible occurrences of month and year. So something like:
/* Get the format of the title */ len = GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, NULL, 0); yearmonth = HeapAlloc(GetProcessHeap(), 0, len); GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, yearmonth, len); /* Find out the order */ year = strstr(yearmonth, "y"); month = strstr(yearmonth, "M");
if (month < year) trace("Month before year\n"); else trace("Year before month\n"); HeapFree(GetProcessHeap(), 0, yearmonth);
Yes, not all possible actually, only month < year condition matters. It's better to use yyyy pattern cause some locales add extra words in this format string. Also a static char[80] buffer should be used to simplify things (btw, MSDN says about 80 character length for all locale data, but we currently use much shorter in some cases - about 10, 30 or so. Unfortunately there's no way to check this max length value, cause it's more like a max resource length. Anyway I'm going to use this value in next patch set maybe cause it's documented at least and isn't so magic like ours).
The 3 tests I removed with the first patch can be removed safely as all should be tested in the loop.
Now I need to change the way we test to cope with:
- order of year/month
Ok.
- text right after the prev button or right before the next button
Not sure what you mean here. Isn't it the same as order?
On 10/01/2009 03:28 PM, Nikolay Sivov wrote:
Paul Vriens wrote:
On 10/01/2009 02:58 PM, Nikolay Sivov wrote:
Yes, please. If a problem is only in rectangle orders it's very simple to fix (test for yyyy in returned locale data). I suggest not to drop tests yet, we'll probably want to drop them later when trying probable dpi-dependent failures.
Well I need to test for all possible occurrences of month and year. So something like:
/* Get the format of the title */ len = GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, NULL, 0); yearmonth = HeapAlloc(GetProcessHeap(), 0, len); GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SYEARMONTH, yearmonth, len); /* Find out the order */ year = strstr(yearmonth, "y"); month = strstr(yearmonth, "M");
if (month < year) trace("Month before year\n"); else trace("Year before month\n"); HeapFree(GetProcessHeap(), 0, yearmonth);
Yes, not all possible actually, only month < year condition matters. It's better to use yyyy pattern cause some locales add extra words in this format string. Also a static char[80] buffer should be used to simplify things (btw, MSDN says about 80 character length for
Yeah, but as I didn't find a nice constant for this I opted for the dynamic one.
The problem with the 'yyyy' pattern is that this is not the only pattern.
year : "yyyyy", "yyyy", "yy", "y" month : "MMMM", "MMM", "MM", "M"
This for example "yyyy maybe MMMM" produces "2007 may7be April" in the title. (There is a limit to what can be used for LOCALE_SYEARMONTH though.)
all locale data, but we currently use much shorter in some cases - about 10, 30 or so. Unfortunately there's no way to check this max length value, cause it's more like a max resource length. Anyway I'm going to use this value in next patch set maybe cause it's documented at least and isn't so magic like ours).
The 3 tests I removed with the first patch can be removed safely as all should be tested in the loop.
Now I need to change the way we test to cope with:
- order of year/month
Ok.
- text right after the prev button or right before the next button
Not sure what you mean here. Isn't it the same as order?
If you change the regional settings to Portuguese (on a Windows box) you see what I mean. There is no room between the buttons and the text.
-
Nikolay Sivov -
Paul Vriens