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