This is not ideal, as resetting the page contents loses the current
selection and redoes a lot of work that could be avoided, but it's
(much) better than nothing, as it fixes the window appearance after e.g.
moving it to another monitor.
Closes#18564.
This replaces the fix of f4dcac9f44 (Return wxFont adjusted to DPI in
wxHtmlWinParser::CreateCurrentFont(), 2020-11-25) adjusting the font
explicitly under MSW with a better fix, associating the correct window
(and hence DPI) with the device context used in OnPaint().
See #18564.
Handling mask when converting wxBitmap to wxImage was accidentally
broken by 7e9afad53a (Add real support for monochrome bitmaps to wxMSW,
2020-10-19). Fix this now and reuse the new wxMonoPixelData to make the
code simpler and more readable.
This commit is best viewed ignoring whitespace-only changes, as it
unindents a large block of code.
Closes https://github.com/wxWidgets/wxWidgets/pull/2125Closes#18974, #18975.
This requires refactoring NewCloseButton() in order to extract
CreateCloseButton() from it, as XRC relies on being able to use two-step
creation which was previously impossible for this kind of buttons.
CreateCloseButton() is rather unusual, as it has to be declared in the
derived, platform-specific class, in order to be able to call its
Create(), but is defined only once in common, platform-independent,
code. However the only alternative seems to be to have a static
function, e.g. InitCloseButton(), which wouldn't be very pretty neither.
Closes https://github.com/wxWidgets/wxWidgets/pull/2118
IsEnabled() wrongly returned true even when the TLW was actually
disabled due to a native modal dialog using it as owner being currently
shown.
Fix this by trusting the actual HWND state, rather than our internal
m_isEnabled, except before the window is created.
Do it for TLWs only even if, in principle, we could check for
WS_DISABLED for the other windows too. However this would make
IsThisEnabled() inconsistent with the other platforms, where it returns
true when the window parent is disabled, but the window itself isn't,
which is currently also emulated by wxMSW, but wouldn't be the case if
we trusted WS_DISABLED presence. And while there might be other problems
due to lying about the actual window state in this function, it doesn't
seem to create any problems in practice, so for now leave the old logic
in place.
As a side effect, this makes wxWindowDisabler work correctly when a
message box is shown by another window when it's created, as it will now
correctly avoid re-enabling the message box parent in its dtor.
Closes https://github.com/wxWidgets/wxWidgets/pull/2117
See #11887.
No real changes, just get rid of an unnecessary instance of
wxWindowList: this one can be safely replaced with a vector because it's
a private member and so changing its type doesn't affect compatibility.
This resulted in a crash when WM_ACTIVATE was received from inside
wxWindow dtor, executed after wxTopLevelWindowMSW dtor, and passed to a
handler defined in wxTopLevelWindowMSW and using its already destroyed
members.
Perhaps we should avoid dispatching any messages when the window is
being destroyed, but it's not totally obvious that this is not going to
break something, so for now apply just this minimal fix.
Closes#18970.
This partially reverts 44d732b8a5 (Use TB_SETBUTTONINFO when updating
stretchable toolbar separators, 2019-02-24) and restores the behaviour
before this commit for the vertical toolbars only, as the new code
doesn't work for them, even though like it seems it should (and we don't
get any error when using it).
Still keep the simpler path for horizontal toolbars, as there doesn't
seem to be any problems with it in this case.
Use correct drop effect in DropCleanup helper added in f5548e399e (Fix
problem with dragged icon remaining on screen under MSW 10, 2020-01-11):
using the value of the input pdwEffect argument was wrong, as it could
be a combination of multiple DROPEFFECT_XXX flags, when we really need a
single one here.
This fixes a regression and the code should do exactly the same thing
now when OnDrop() does not throw as it had done before that commit.
See #18499.
Closes#18965.
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
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.
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 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
