Unlike wxGridCellDateRenderer, which already did it, the editor class
always got the cell value from the table as a string, even if the table
supported returning the dates directly.
Fix this by using the same code in the editor as in the renderer, which
required a further refactoring in order to make it reusable: the helper
TryParseDate() was replaced with TryGetValueAsDate() and DateParseParams
was added to allow overriding the arguments passed to it in the
overridden wxGridCellDateTimeRenderer::GetDateParseParams().
This function is inherited from wxGridCellDateRenderer since the changes
of 659ab78c6d (Add support for editing dates (without time) to wxGrid,
2018-09-06), so there is no need to document it separately.
This is needed to allow editing the cells using wxGridCellDateRenderer
with a custom format, otherwise the editor might parse the contents of
the cell differently from what is actually shown.
In particular, this ensures that using "date:%d.%m.%y" (or any other
custom format) as "cell type" works correctly, which wasn't the case
before.
For the tables that store dates as strings, we must use the specified
format for interpreting the table data, as otherwise we could confuse
the user by showing it incorrectly: for example, if "%d.%m.%y" format is
used, "01.03.02" should really mean 2002-03-01, but it was parsed as
0002-01-03 by ParseDate() which had no choice but to guess the order of
data components.
This fixes a bug due to a typo in ab02d36e10 (Account for vertical
alignment in wxGetGridCheckBoxRect() too, 2019-11-22) which used the
vertical component of a wrong object and so didn't actually offset the
checkbox by its size from the bottom of the cell rectangle, as it should
have done.
Closes#18907.
Use the best size and not the actual size of the toolbar in
wxFrame::PositionToolBar(), called from SetToolBar(), as for a toolbar
which had been previously realized its size could have been set to the
entire client area size -- as is normal for any non-special child
window, and before being associated with the frame using SetToolBar() a
toolbar is not special too.
Using the current size was probably a workaround for GetBestSize() not
returning correct results in wxMSW and so shouldn't be needed any longer
after the changes of 1a79610361 (Rewrite wxToolBar resizing logic in
wxMSW, 2019-02-24) and now just results in using wrong size for toolbars
not created using CreateToolBar().
Closes#18954.
When doing an RGB->HSV->RGB roundtrip, the original value should be
restored (HSV, being double, has sufficient precision).
For e.g. `RGBValue(1,2,3)`, the equivalent resulting code for blue is
`trunc(int * 255.0 / 255.0)` (cast from double to int truncates).
At least with x87 FP math and its immediate 80bit extended precision
the resulting value is ~trunc(2.9999..), i.e. 2, similar problems may
exist on other architectures with other values.
Using proper rounding avoids the error magnification.
Closes https://github.com/wxWidgets/wxWidgets/pull/2078
This reverts commit 7ec39330d2 because
enabling verbose ASAN output results in too much output for Travis to
handle (and, to be fair, for it to be useful).
In order to be able to use monochrome bitmaps as wxMask, improve support
for them in various ways:
1. Implement loading and saving of monochrome BMP files.
2. Add wxMonoPixelData for direct access to monochrome bitmap pixels.
3. Implement conversion from wxImage to monochrome wxBitmap.
Closes https://github.com/wxWidgets/wxWidgets/pull/2032
While technically it still builds with older versions,
version 1.0.622.22 ist the first non preview release which should
make the included webview loader DLL the most compatible for the
forseable future.
This is useless, all still supported compilers except ancient MSVS
versions (for which configure is not used anyhow) support variadic
macros, so don't waste time testing for them.
Note that the checks for HAVE_VARIADIC_MACROS in the sources are still
left because it is still possible to explicitly disable variadic macros
support using --disable-vararg_macros for strict C++98 compatibility.
All still supported versions of MinGW/Cygwin provide w32api.h file, so
there is no need to test for it.
This allows to simplify the code, but also remove the definition of
HAVE_W32API_H from bake- and makefiles and this, in turn, allows to get
rid of extra flags in MinGW format entirely, as we don't support gcc
2.95 for which they were originally needed neither.
Fix issues found by address/leak sanitizers in the unit tests and add
Travis CI build running tests built with ASAN to ensure they don't
reappear in the future.
See https://github.com/wxWidgets/wxWidgets/pull/2086
The version of glibc used under Ubuntu 20.04 doesn't have "%Z" in the
French date-time locale, which broke the test there.
Instead of adding even more tests for glibc version, just ignore "%Z" if
it's present, we don't really care about it, we just want to check that
wxLocale::GetInfo() returns something recognizably different from C and
English locale here.
Don't rely on just a single GTK version being installed on the system,
as we do now, but select the version we want explicitly, just to avoid
bad surprises in the future (even if it doesn't change anything for
now).
It default to 2 currently, which is rather surprising, so prepare for
requiring specifying it explicitly by adding wxGTK_VERSION to all wxGTK
builds environments.
