No real changes, just add a helper wxDumpWindow() function to make focus
logging less verbose and slightly more readable (as the label is not
shown any more if it's empty).
Previously this was done only for wxSearchCtrl, extend this now to all
the widgets in order to be able to check whether the expected events are
generated.
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.
This amends a0298f3149 by only avoiding
dispatching of the native events in nested event loops, but still
dispatching any pending wx-level events before exiting it.
The latest code still solves the original problem, as it was due to
having an endless stream of native events, without possibly introducing
new problems and even crashes if, for example, some dialog event handler
queued an event referencing the dialog itself for later procession, as
this event must be dispatched before the loop exits and the dialog is
destroyed, which wasn't the case any more after the changes of
a0298f3149 but is done again now.
See #11273.
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.
Add wxPNGImageData and use it to store variables that used to be local
in wxPNGHandler::LoadFile() and could be clobbered by the use of
longjmp() and pass these variables to DoLoadPNGFile(), which still uses
longjmp(), whereas LoadFile() doesn't any longer.
In addition to fixing the warning, this allows to use C++ dtors for
freeing memory and makes the code shorter and, arguably, more clear than
the original version (although written in an unusual way) and definitely
more clear than the version with the warning fix.
This reverts commit 99ea06203a ("Fix
clobbering warning") and replaces it with a different solution to the
same problem.
Previously this was only done when wxBU_AUTODRAW was specified, making
this the only place in wxWidgets where this style was actually used.
This was not ideal, as the same code, not using wxBU_AUTODRAW, worked
just fine under MSW and GTK, but created ugly-looking buttons under Mac,
so do the right thing by default and let people call SetMargins(0, 0) if
they really don't want to have any margins.
Closes#18170.
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.
As usual, when changing the background colour, we need to change the
foreground as well, otherwise the text risks becoming unreadable with
some default text colour values -- as was the case under GTK+ 3 with its
default theme.
Due to https://bugzilla.gnome.org/show_bug.cgi?id=710888 GtkInfoBar
wasn't shown if it had been hidden before -- which is exactly what
wxInfoBar did.
Fix this using the workaround proposed in the bug report, which makes
the info bar appear immediately, without any transition, which might be
not ideal, but markedly better than failing to show it at all.
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