Make the (originally) auto-generated code of this dialog slightly more
readable by replacing some auto-generated variable names with more clear
ones.
Also avoid using FindWindow(), this is useless and we already have the
window pointers.
Closes https://github.com/wxWidgets/wxWidgets/pull/872
Base class SetTitle() implementation didnd't work for this class as it
used the (invalid) HWND of not yet existing dialog, so add a hook
procedure for the common font dialog, similar to the existing one for
wxColourDialog, which allows us to set the dialog title when the dialog
is really created.
Closes https://github.com/wxWidgets/wxWidgets/pull/865Closes#18177.
Add a check ensuring that if wxCheckListBox is disabled, then so is
wxRearrangeCtrl, to avoid build errors that would happen otherwise.
Closes https://github.com/wxWidgets/wxWidgets/pull/866
It was impossible to stop sorting the control if it had been sorted
before, so implement UnsetAsSortKey() to allow doing it by destroying
the current sort descriptor.
Closes#18176.
Previously, wxEVT_{SET,KILL}_FOCUS event handlers were connected to all
children, even the indirect ones, which resulted in duplicate focus
events if a grandchildren forward its focus event to its parent window,
as happens e.g. with wxComboCtrl, which contains a text control that
forwards its focus events to the containing control itself.
This change seems globally sound, even if it might break some controls
whose children don't get the expected focus events themselves, because
the right thing to do is to fix those children. And it fixes duplicate
focus events in wxDatePickerCtrlGeneric.
Revert 1de107c037 and remove the focus
event handler which duplicated and interfered with the handler inherited
from this class to make sure that we get wxEVT_{SET,KILL}_FOCUS for the
objects of this class.
Unfortunately these events now come in pairs, due to an extra artificial
event generated by wxComboBoxExtraInputHandler::OnFocus(), which is
still wrong -- but arguably less wrong and more useful than not sending
them at all.
This fixes a compilation error in wxMSW private fonts support
implementation, which compares wxString with a wide string but, unlike a
local fix there, makes sense more broadly and should reduce the
likelihood of similar errors in the future.
It also makes comparisons with narrow C strings more efficient in the
default, Unicode, build by using wxString::Cmp() method instead of
creating a temporary wxString, as was done before.
See #18172.
While this doesn't make, and never made, any sense (pointers should be
stored in a plain, non-object array), we still should continue to
support it for compatibility.
Fix the problem introduced by 97684a9267
by writing "T const&" instead of "const T&" as the latter didn't have
the same meaning when the macro parameter "T" expanded into "U*" as
"const" applied to "U", making this type incompatible with the actual
one.
Also extend the unit test to check for this.
Changing item cell in ShowAsRadio() was wrong as the item cell doesn't
exist when it is called and changing the column cell didn't seem to work
well, so just recreate the entire cell in it instead.
See https://github.com/wxWidgets/wxWidgets/pull/853
Avoid stringop-overflow warning about strncpy size argument depending on source size.
Checking for null in src is not needed because it is already checked by strlen.
This allows showing radio buttons in wxDataViewCtrl easily and natively.
Notice that this approach, adding an extra function to the existing
renderer class instead of creating some new wxDataViewRadioRenderer (see
https://github.com/wxWidgets/wxWidgets/pull/809), was finally chosen
because it is simpler to implement and, more importantly, because it
will be more natural to generalize if/when we also add a 3-state
check/radio renderer.
Closes https://github.com/wxWidgets/wxWidgets/pull/853
Changes of c0b0562533 to common code broke
wxGTK1 build, as wx/gtk/private/wrapgtk.h is for wxGTK 2+ only.
Fix this by handling wxGTK 1 separately and including gtk/gtk.h directly
for it.
Hopefully this code will be removed, together with the rest of wxGTK1
support, in some not so distant future.
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.
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.
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.
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.
