Don't use invalid SYSTEMTIME returned by DateTime_GetRange() under WINE which
always returns GDTR_MIN, even if the min value is not actually valid, see
https://bugs.winehq.org/show_bug.cgi?id=40301
This avoids an assert which otherwise happened whenever wxDatePickerCtrl was
created.
If the old value didn't lie inside the new range, it was changed by the native
control internally but the value stored by wxDatePickerCtrl itself remained
unchanged, resulting in asserts later when the mismatch between them was
detected.
Closes#13189.
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just refactor wxMSW wxDatePickerCtrl to allow sharing code
with the upcoming wxTimePickerCtrl class. Even less changes for the other
platforms where wxDateTimePickerCtrl is trivial.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69222 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The bug fix of r67990 relied on DateTime_SetSystemtime() returning FALSE if
setting the date failed but, unfortunately, this function doesn't behave
correctly under XP (and presumably earlier systems) and returns TRUE even if
it didn't actually change the date because it was out of range.
Implement an alternative solution not relying on this function return value
but simply checking the range ourselves.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68027 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The internally stored date value was getting out of sync with the real date in
the control itself when SetValue() was called with a date out of the currently
set range. This resulted in an assert failure and other unpleasantness later.
Fix the bug and add a unit test checking for it (and also with some other
basic wxDatePickerCtrl checks).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67990 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is similar to the fix of r64208 for wxCalendarCtrl and ignores the time
component of SYSTEMTIME objects returned by the native functions in
wxDatePickerCtrl too to ensure that we operate with pure dates only.
Closes#12493.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65573 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2. use HandleWindowEvent() everywhere as more obvious and convenient shortcut for GetEventHandler()->ProcessEvent(); also for consistency with wxGTK where it's required
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@50329 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
1. the main function for item insertion is now DoInsertItems() which allows
for much more efficient addition of many new items at once
2. the items client data management is done entirely in wxItemContainer
itself, the derived classes don't have to distinguish between void and
object client data
3. many fixes for sorted controls, in particular implemented wxCB_SORT support
in wxGTK combobox
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@47730 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Paul Cornett: A static class member can be accessed as X::member,
there is no need for an object or pointer (s.member or
p->member). There are also a few bugs with incorrect
usage of wxString::Format and wxString::FromAscii.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@33188 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
