Replace SetListRulesAlternateColourOnBlank() taking 2 arguments, with
the second of them being used only when the first one is true, with a
simpler but still sufficient ExtendRulesAndAlternateColour(bool).
Make the new method virtual and define it as doing nothing in
wxListCtrlBase class, so that it's still available, even if currently
not implemented, in wxMSW.
Also simplify the implementation, fix style problems and other minor
improvements.
Previously they were both limited to the part occupied by the items
only, add a new method allowing to extend them to the whole client
window area.
See https://github.com/wxWidgets/wxWidgets/pull/2106
Make the overloads added for compatibility available only when
WXWIN_COMPATIBILITY_3_0 is on and add two more of them, to cover all the
interer types (except char but, honestly, who rounds those?).
Also improve the documentation and make it clear that this function is
not needed at all in the new code.
Closes https://github.com/wxWidgets/wxWidgets/pull/2111
Check if edge webview runtime is available in the call to
wxWebView::IsBackendAvailable() instead of only doing it during
process initialization. This allows an application to install
the Edge WebView2 Runtime during runtime and use the edge webview
afterwards without restarting the process.
Tell the SDK controller if the control is shown or hidden.
This allows creating a hidden webview which will be shown later
and might fix other potential issues.
Setting EnableContextMenu and EnableAccessToDevTools where
ignored before the webview loaded content. This would often
be set directly after creation and work like this with other
backends.
This allows to customize the string shown when there is no valid date
under MSW (only, for now) and can be notably used to suppress the
unused date completely, which can be useful to lighten up the display
when there are many controls.
Add UI elements to the widgets sample allowing to test the new function.
DatePickerWidgetsPage::OnDateChanged() must check whether the wxDateTime
value received from the control or event is valid before formatting it,
as this may not be the case when wxDP_ALLOWNONE is on, and trying to
format an invalid date results in assertion failures (and random junk in
the output).
This class must not derive from the native wxDatePickerCtrl, as it
doesn't make much sense and resulted in the need for an ugly hack with
either overriding unused and inapplicable pure virtual methods in this
class itself, as was originally done in 569c7d8ccb (Add wxTimePickerCtrl
class., 2011-09-29) when it was introduced, or not making these methods
pure virtual in the first place, as was done in d0da5061ce (Dirty hack
to allow generic wxDatePickerCtrl to compile under MSW., 2011-10-20),
but didn't really fix the problem.
Do fix it now by using different hierarchies for the native and generic
classes. The main disadvantage of doing it is that there is no common
base class for wxTimePickerCtrl and wxTimePickerCtrlGeneric providing
SetTime() and GetTime() methods any more, but this seems like a
relatively small price to pay because real applications won't be using
these two classes simultaneously, as the calendar sample does, anyhow.
When not using an anchor, new page must be shown starting from its
origin in the top-left corner, instead of remaining at the current
scroll position, as it did before.
Closes#18922.
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
