Undocumented behavior wxMSW date/time picker change in 3.3

[PBfordev]

(based on a wxForum post)

Unlike in previous versions, date and time pickers in 3.3 are locale-aware by default, see 6bcbcf9 This can be seen in the samples.

This may surprise some people who do not properly set the (UI) locale in their application, where the controls now use the C locale whereas they used the system locale before.

So, this change should probably be documented.

BTW, perhaps the fact that applications not having a manifest now show a (untranslated) message stating that, even in the non-Debug builds; should be documented as well.

[PBfordev]

Ooops, sorry, the change regarding locale-awareness is actually documented, I somehow did not find it before.

However, it is not in where I expected it, i.e., in the section Changes in behaviour not resulting in compilation errors

[vadz]

Yes, I agree, this should be documented more prominently. I'm not 100% sure about the exact wording though: from the forum post, it looks like the behaviour has changed even when not using/setting locale?

About the manifest: I think the error itself is good enough, there is no chance of somebody not noticing it.

[PBfordev]

from the forum post, it looks like the behaviour has changed even when not using/setting locale?

I think the issue is when one does not set the locale at all and it now defaults to C instead of the user; just like with the samples. Of course, not setting the locale is IMO a programmer error, but still...

[vadz]

I think this is is what @utelle's intention was. AFAIR I wasn't sure that it was the right thing to do back then, and I'm still not sure now...

[utelle]

I think this is is what @utelle's intention was.

Correct. In prior wx versions the Windows date and time picker control always used the system locale, independent of the locale set within the wx application. This leads to inconsistent behaviour, because the date/time formatting methods use the actually set locale, while the picker control possibly uses a different one. Could be seen in the i18n sample in the data grid, where the date is displayed in the selected locale while the picker uses the system locale.

AFAIR I wasn't sure that it was the right thing to do back then, and I'm still not sure now...

IMHO the behaviour in 3.3 is more consistent. For a locale aware application the locale should be explicitly set. If the locale is not set, the C locale will be used. Why should such an application with an unset locale display for example numbers in English (C locale) notation, but date pickers in the current system locale? With a set locale the behaviour will be as expected.

[PBfordev]

Just to make clear: I was not arguing for reverting the change, I just wanted to list it among those changing the behaviour compared to 3.2.

The change makes it somewhat consistent, for example, wxSpinCtrl uses "." as the decimal separator. BTW, in the widgets sample the time picker still shows the Czech "odp." instead of "p.m." but I guess that can't be helped.

Somewhat off topic BTW: StrCmpLogical() which we use for natural sorting on Windows (and thus likely displaying those strings to users), seems to be using the default system locale instead of the "application" locale. Could perhaps be replaced with CompareStringEx(), but...

[vadz]

I agree that this needs to be documented, so reopening.

I'm still not sure about the consistency argument. It's good in theory, of course, but in practice the difference is that many locales use the same numbers representation as C locale, but much fewer of them use the same date/time representation, so the difference is much more noticeable.

The really right thing to do would be to do wxUILocale::UseDefault() by default but this would be an even more breaking change :-(

[utelle]

Just to make clear: I was not arguing for reverting the change, I just wanted to list it among those changing the behaviour compared to 3.2.

As @vadz already said it will certainly be good to document this change in more detail.

The change makes it somewhat consistent, for example, wxSpinCtrl uses "." as the decimal separator.

BTW, in the widgets sample the time picker still shows the Czech "odp." instead of "p.m." but I guess that can't be helped.

Indeed the options to modify the Windows date/time controls are limited. Especially the calendar control does not support modifications. No idea whether alternatives exist.

Regarding the Czech "odp." vs "p.m." I suspect that this text string is not part of the format string, but is set based on the selected date format - 12 hours vs 24 hours.

Somewhat off topic BTW: StrCmpLogical() which we use for natural sorting on Windows (and thus likely displaying those strings to users), seems to be using the default system locale instead of the "application" locale.

AFAICT StrCmpLogical() does not involve any locale.

[utelle]

I'm still not sure about the consistency argument. It's good in theory, of course, but in practice the difference is that many locales use the same numbers representation as C locale, but much fewer of them use the same date/time representation, so the difference is much more noticeable.

Well, it is certainly possible to find arguments for both variants. Personally, I find it very annoying if an application displays dates in American style (i.e. C locale or en_US locale), but the date editor then uses the system locale (which is German in my case) - as it was in wx 3.2. Very easy to enter invalid dates.

However, it depends on the actual use case, which variant users prefer and experience as "natural".

In fact, the best option would be to use date/time controls that take the current application locale into account in a natural way. The currently used Windows controls unfortunately do not fulfill this requirement.

[PBfordev]

(I closed the Issue before by accident, for the second time this day)

AFAICT StrCmpLogical() does not involve any locale.

While it is not documented, I think it does use the "Windows" locale. IIRC, when I used it, it correctly sorted something like "Chris" after 'Hana", because in Czech we have a digraph "ch" which when compared is to be treated as a single letter sorted between H and I. But this is a complex issue: For example, AFAICT, the files and folder in the file/dir dialogs (IFileDialog) are always sorted in the system/user locale (Czech for me), even when the application did not set any locale (i.e., is using C locale).

[utelle]

AFAICT StrCmpLogical() does not involve any locale.

While it is not documented, I think it does use the "Windows" locale.

Yes, you are right - never trust the M$ documentation. At least the function uses the sorting rules of the system (and that is locale dependent).

Looking at the M$ documentation I see the following note:

Note Behavior of this function, and therefore the results it returns, can change from release to release. It should not be used for canonical sorting applications.

Not very trustworthy I must say.