This is especially important under MSW, where the modality of the nested
event loops actually ends as soon as wxModalEventLoop::Exit() is called,
and so we must avoid dispatching any events in the current loop after it
happens or we risk reentering the same loop again, which could result in
e.g. parent modal dialog being closed before the child event loop
returns (because the event closing the former was dispatched from the
latter) and other unexpected sequences of events.
To prevent this from happening, only dispatch pending events after the
loop exit if it's the outermost loop, as there should be no danger in
doing it in this case. Conversely, we don't lose anything by not doing
this in nested event loops as the outer loop will take care of any
remaining pending events anyhow.
To make this work in an ABI-compatible way, add a global counter of the
currently existing event loops which is used to check if there is more
than one event loop currently running.
Closes#11273, #11573, #11269.
Don't leave "m_hover" invalid if the number of columns in wxHeaderCtrl
is reduced, as this would result in a crash later when it is used.
This notably fixes a crash after removing the last column from generic
wxDataViewCtrl.
Closes https://github.com/wxWidgets/wxWidgets/pull/852
It was too high otherwise, which was especially noticeable in high DPI.
This is still not perfect, as the default search bitmap is not centered
neither and is a couple of pixels too high, but better than before.
Apply DPI scaling to the extra vertical margin added by this macro to
the font height.
This makes sense and results in wxTextCtrl (and other controls, e.g.
wxSearchCtrl) having the same height as native ones when using high DPI
too.
Note that this required adding wxGetEditHeightFromCharHeight() function
as one of the existing uses of EDIT_HEIGHT_FROM_CHAR_HEIGHT() wasn't
inside a wxWindow-derived class method and also adding wxUSE_GUI guard
around these GUI-only definitions as a function, unlike a macro, can't
be compiled without full wxWindow declaration in scope.
There is no need to override this virtual function, if the control size
changes, a wxEVT_SIZE event is generated in any case, resulting in a
call to LayoutControls() without explicitly calling it from here.
There doesn't seem to be any reason to have these flags, which duplicate
the visibility state of m_searchButton and m_cancelButton respectively.
Also update the buttons visibility immediately in ShowSearchButton() and
ShowCancelButton() instead of doing it in LayoutControls() as before,
which was confusing as laying out is not supposed to show/hide anything.
Finally, return true, not false, from IsSearchButtonVisible() if the
button is actually visible because there is an associated menu, even if
ShowSearchButton(false) had been called. This seems more logical and
makes the code simpler, but we need to check whether the native Mac
version also behaves like this or not.
No other changes in behaviour.
Replace LIGHT_STEP macro and 20 magic number with
SEARCH_BITMAP_LIGHTNESS and CANCEL_BITMAP_LIGHTNESS constants which are
a bit more clear, hopefully.
No real changes.
Make this button of exactly the bitmap size instead of using the full
control height for it, even if/when the bitmap is smaller.
This fixes some random junk being shown in the bottom two pixels of the
search button sometimes: this was due to only redrawing the part covered
by the bitmap in wxSearchButton::OnPaint(), leaving the rest of the
button unpainted (because wxSearchButton uses wxBG_STYLE_PAINT).
Checking for the exact match of __GXX_ABI_VERSION created more problems
(including for both Fedora and Debian packagers, see
https://github.com/wxWidgets/wxWidgets/pull/828) than it solved
(approximately 0), so relax it and assume that future g++ versions will
remain broadly compatible with the current ABI, which seems like a safe
assumption so far.
It's not really clear if there is any value in having this ABI check at
all, or if we should remove CheckBuildOptions() and all the code calling
it entirely, as it seems that there is no way to trigger this check
during run-time without getting a link error first. But keep it for now,
just because it's simpler to keep it than to remove it.
Don't invent yet another std::max-macro. We probably could just use the
standard function instead but for now use wxMax(), for consistency with
the rest of the code base.
No real changes.
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.
