Displaying error dialog can cause on some platforms native focus changes
what triggers unwanted focus change events in wxPG and disturbs expected
sequence of events. To prevent this from happening (regardless of platform),
we need to save focused window before dialog box is displayed and restore
it after closing the dialog.
Closes#18046.
Recent 3518f1a7d8 broke IsMaximized()
return value when the window was visible and had been previously
maximized by calling Maximize(), but wasn't actually maximized any
longer because it started to always return true when m_showCmd was set
to SW_MAXIMIZE.
Fix this by only using m_showCmd when the window is hidden, as it
shouldn't matter what it is when it's shown. Also simplify/optimize the
logic of IsMaximized() to use either ::IsZoomed() or m_showCmd depending
on whether the window is shown or not, but not both.
See https://github.com/wxWidgets/wxWidgets/pull/842Closes#18163.
Changes of commit cf20a9ced5 suppressed
the generation of the initial wxEVT_SIZE for hidden wxFrames, as the
initial WM_SIZE was ignored. This went unnoticed for "normal" frames,
which got another WM_SIZE when they were shown in any case, but broke
frames with wxFRAME_TOOL_WINDOW style as they're shown using SW_SHOWNA
command and in addition to suppressing activation, it also suppresses
the generation of WM_SIZE, so such frames didn't get any wxEVT_SIZE at
all and appeared without being laid out properly, as could be seen, for
example, in the splash sample.
Fix this by continuing to generate the size events even for hidden
frames, just as we did before, while still skipping all the other stuff
which is not necessary for the hidden windows.
See https://github.com/wxWidgets/wxWidgets/pull/842Closes#18161.
The opening <font> tag was only written to the output if the style had a
non-default font, but the matching closing tag wasn't guarded by the
same check.
Do add the check now to ensure that the tags are always balanced.
Closes#18157.
Mention that the "name" is interpreted as the label if no window with
such name is found.
Also document that both this and FindWindowByLabel() functions do
recurse into child TLWs, unlike FindWindow().
Current behavior of AddArcToPoint() when there is no current point is not
documented and moreover it is not the same in native macOS and in generic
implementation. Under macOS nothing is done and "no current point" error
is raised but under other ports (generic implementation) only arc
is drawn (without initial line).
When there is no current point, in similar functions AddCurveToPoint(),
AddQuadCurveToPoint() it is initially set to the some known control point
of the curve but this approach cannot be applied to AddArcToPoint().
The only well defined fallback point seems to be (0, 0) and this option
is implemented here.
See #18086.
After executing native operations on the graphics path, the native
current point is updated properly and should be used instead
of manually maintained logical point.
See #18111.
Just test m_blockEvents directly, there doesn't seem to be any gain in
using an accessor here.
Also test it only once instead of doing it twice in
MacHandleSelectionChange().
Prevents deselecting the selected item in single-selection listbox.
Also generate correct events in the multi-selection case by reusing the
existing wxListBoxBase::CalcAndSendEvent() method.
Closes#15603.
Passing an empty std::vector<wxString> to Append() or Insert() methods
of any wxItemContainer-derived classes, such as e.g. wxComboBox,
resulted in undefined behaviour due to accessing the first element of an
empty vector.
Fix this by avoiding using it when the vector is empty.
For some reason lost in the depths of time (but probably just a typo)
(but probably just a typo) (but probably just a typo) (but probably just
a typo), SetItem() overload taking the column index returned "long" and
not "bool", even though the actual return value was always "true" or
"false" (or even just always "true" in the case of the generic version).
Change it to return "bool" for consistency with the other overload and
because this just makes more sense and shouldn't break any existing code
due to the implicit conversions between bool and long.
Also document the return value meaning.
Closes#18153.
AddArcToPoint() on macOS port is implemented with native API (CGPathAddArcToPoint) so its behaviour should be considered as a reference for generic implementation used in another ports.
Closes#18086.
This is done by explicitly calling Update() in the generic version and
seems to also be done by the native MSW one, even if it's not documented
to do it.
Apparently changing the window scrollbars in the middle of a window
deferred repositioning operation is not allowed and confuses
EndDeferWindowPos() which doesn't update the position of _grand_
children correctly in this case.
This bug notably manifested itself when loading a wxScrolledWindow
containing wxStaticBox from XRC, as the parent window was initially
created with the default small size and then relaid out when it was
resized to its real size on first wxEVT_SIZE event which also updated
the scrollbars. As a result, the children of the wxStaticBox were
shifted downwards.
The fix simply flushes the current repositioning operation and starts
one anew in wxWindow::SetScrollbar().
This doesn't really change anything, but just skips executing some code
uselessly if we know in advance we are not going to do anything, which
is nice as ScrollWindow() actually ends up being called with 0 arguments
surprisingly often from wxScrollHelperBase::SetScrollRate().
This is also consistent with what wxGTK does.
Rewrite CreateLayout() using SetVirtualSize() to avoid trying to detect
whether the vertical scrollbar is shown manually. This is simpler and
avoids the problem of entering infinite loop if the scrollbar size used
by this function (based on wxSystemSettings::GetMetric(wxSYS_VSCROLL_X))
wasn't correct, as used to be the case for wxGTK until the recent commit
900752b152 and might still be the case in
the other ports.
Closes#18141.
This reverts commit e771b7e4ac5c7f73a579f7329ce15e2d6710670d.
Don't always pass WM_SYSKEYDOWN to the system for processing as this can
be undesirable: e.g. inside a dialog, any Alt-X key presses with X not
being a mnemonic character result in a beep from IsDialogMessage().
Handle events for the system keys in the same way as for the normal
ones, i.e. let the system process them only if they're not handled by
the application.
This is incompatible with the previous wxMSW behaviour, but compatible
with the other ports and makes more sense, so it seems to be worth it,
on balance.
When wxColourDialog is shown, any changes to the colour selected in it
apparently result in broadcast messages to all currently visible text
controls, which was unexpected.
Block the changeColor: message to prevent this from happening.
Closes https://github.com/wxWidgets/wxWidgets/pull/830
