Changelogs

Fix bug when setting an out of range date in wxMSW wxDatePickerCtrl. 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).

2011-06-20 00:46 VZ, revision 67989

Extract wxDateTime-related cppunit helpers in a separate header file. No real changes, just refactor the code to allow using CPPUNIT_ASSERT_EQUAL with wxDateTime in other tests in the future.

2011-06-20 00:46 VZ, revision 67988

M /wxWidgets/trunk/interface/wx/datectrl.h

Document surprising behaviour of wxDatePickerCtrl::GetRange() in wxMSW. wxMSW native control always has a built-in lower limit as MSW doesn't support the dates before the year 1601 so wxDatePickerCtrl::GetRange() always returns a valid range start, even if SetRange() hadn't been called to set it. As this can be unexpected, document this behaviour clearly.

2011-06-20 00:46 VZ, revision 67987

Implement wxCalendarCtrl::SetDateRange() in the native GTK version. While GTK+ doesn't support imposing ranges for dates selection natively, we can do it ourselves by preventing the user from selecting any date outside of the currently valid range. This allows to use ranges under all platforms and not only in wxCalendarCtrl itself but in wxDatePickerCtrl as well.

2011-06-20 00:46 VZ, revision 67986

M /wxWidgets/trunk/src/msw/debughlp.cpp

Suppress harmless gcc warnings about enum elements unhandled in switch. Latest mingw64 MinGW compiler has the headers required for enabling wxUSE_DBGHELP, fix the warnings given by g++ when compiling wxDbgHelpDLL code.

2011-06-19 22:52 PC, revision 67985

M /wxWidgets/trunk/src/gtk/button.cpp

fix GTKGetLabel() and DoApplyWidgetStyle(): children are GtkWidget, not GtkBoxChild

2011-06-18 21:40 SC, revision 67984

M /wxWidgets/trunk/build/osx/wxiphone_in.xcodeproj/project.pbxproj

adding universal as devices

2011-06-18 18:47 SC, revision 67983

M /wxWidgets/trunk/samples/minimal/minimal_iphone.xcodeproj/project.pbxproj

adding universal as devices

2011-06-18 18:46 SC, revision 67982

adding instantiated xcodeproj

2011-06-18 17:53 SC, revision 67980

M /wxWidgets/trunk/build/osx/wxiphone_in.xcodeproj/project.pbxproj

removing obsolete flags, switching to universal builds

2011-06-18 17:23 SC, revision 67979

M /wxWidgets/trunk/src/osx/carbon/graphics.cpp

fixing iphone build

2011-06-18 16:30 SC, revision 67978

M /wxWidgets/trunk/build/osx/wxiphone_in.xcodeproj/project.pbxproj

updating project format to 3.2

2011-06-18 16:21 SC, revision 67977

removing old settings

2011-06-18 14:03 PMO, revision 67976

Update to trunk r67975

2011-06-18 13:32 PMO, revision 67975

Added panel.h, panel.cpp

2011-06-18 13:28 PMO, revision 67974

Use common Init

2011-06-17 23:53 VZ, revision 67973

Fix g++ warnings about initialized variables being declared extern. Don't declare variables extern when initializing them, this is already the case implicitly anyhow and explicit "extern" results in g++ warnings.

2011-06-17 23:53 VZ, revision 67972

M /wxWidgets/trunk/src/msw/gdiplus.cpp

Use GdipStringFormatCachedGenericTypographic hack for MinGW as well. When using GDI+ with MinGW, the same hack as for Cygwin is needed (see r66787) as it uses the same w32api headers and libraries for GDI+ support (if it has them at all). See #11716.

2011-06-17 23:53 VZ, revision 67971

M /wxWidgets/trunk/include/wx/dlimpexp.h

Don't use __declspec(dllexport) for MinGW gcc 4.5 and later. Due to the changes in gcc 4.5, copies of dllexported inline functions are now generated in all object files including their declarations, increasing their sizes tenfold, and they are also now instantiated in the DLL itself increasing its size fourfold. Moreover, linking such a gigantic DLL requires inordinate amounts of memory and takes a very long time, see some statistics at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601. To avoid all these problems, don't use dllexport at all any more but rely on binutils support for auto export/import which seems to work fine and results in much smaller DLLs which are created much faster.

Select page:

[<<] [1 54 106 159 160 161 162 163 578 994 1409] [>>]

FileZilla

The free FTP solution.

FileZilla

FileZilla Server

Community

General

Development

Other projects

Changelogs

Overview

Select Changelog:

Select page:

Changes per page:

Changelog for wxWidgets (70435 changes):

Select page: