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 e771b7e4ac.
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
Since the changes of 6ae7aa4443, the
windows were shown when their geometry was restored as a side effect of
calling ::SetWindowPlacement(). This was unexpected and resulted in
flicker on startup, so fix this by explicitly passing SW_HIDE to
SetWindowPlacement() if the window is currently hidden and storing the
real show command inside wxTLW itself, where it will be used when it's
finally shown.
This single field replaces m_iconized and m_maximizeOnShow which were
not really independent and will make it simpler to schedule either
maximizing or maximizing the window later, when it can't be done
immediately because the window is hidden, in the following commit.
Ensure that another TLW is active before calling ShowWithoutActivating()
as otherwise the newly shown window would be considered active, even if
it actually isn't, because it contains the current focus.
Add wxHtmlEasyPrinting::SetPromptMode() to allow suppressing the
"prompt" shown by wxPrinter::Print() when it's called from this class
code.
Closes https://github.com/wxWidgets/wxWidgets/pull/838
After the recent dynamic array macros refactoring, there was no
implementation of wxBaseArray any more and only wxArrayString-related
code remained in this file, so just move the latter to arrstr.cpp, where
it should have been put from the beginning (except that this code
probably predates arrstr.cpp addition), and remove the old file
entirely.
This class doesn't have any non-inline methods and so doesn't need to be
exported from the DLL.
This also avoids warnings in MSVC DLL build about using non
dll-interface class wxArrayTreeItemIdsBase as base for dll-interface
class wxArrayTreeItemIds (C4275).
The new method returns a boolean flag which indicates whether there is
any clipping region or not and so is preferable to using the old one and
checking its return value to determine this, which can't be done
reliably.
