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
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.
