Under wxMSW this method is re-entered due to triggering EVT_ACTIVATE when EVT_LEFT_UP is being already handled.
We need to prevent this to avoid generating spurious EVT_TEXT events and raising errors on calling SetFocus().
Closes#18260.
Dragging a column header in a wxHeaderCtrl and dropping it past the
rightmost column resulted in a crash due to accessing a column with
invalid index.
Fix this and correctly move the column to the last position when this
happens instead.
This bug notably affected dragging columns in wxGrid.
Closes https://github.com/wxWidgets/wxWidgets/pull/972
This fixes the access specifier effectively used for the members
following these macros, as it's changed to "public" inside them, meaning
that e.g. m_privateContextMenu was actually public even though it was
ostensibly declared in the private section and the intention was for it
to be private.
Closes#16038.
Defining a Mac-specific Create(wxMemoryBuffer) overload hid the other
Create() overloads, which are actually part of the public API, so they
couldn't be used any longer since the changes of
e7d21f6638
Fix this by renaming this Create() to OSXCreate(), to avoid hiding the
base class methods.
Also remove Mac-specific ctor taking wxMemoryBuffer, this is confusing
and can be avoided by just calling OSXCreate() directly in the only
place where it is used.
This method allows to retrieve the window this context is associated
with, if any.
Add "wxWindow*" argument to wxGraphicsContext ctor and provide the
window pointer to it when available, i.e. when creating the context from
a wxWindow directly or from wxWindowDC, which is also associated with a
window, in platform-specific code.
No real changes yet.
As SendEvent() not only sends the event about clicking on the link, but
also opens the link in the default browser if this event was not
processed (which wasn't really obvious from its name, so at least
mention it in its comment), the event is actually always handled and so
MSWOnNotify() must return true, not false (and definitely not 0) to
indicate it.
Closes#18266.
The documentation comment belongs to interface/wx/math.h, not the header
under include.
Also change the argument type to wxUint32 as the non-gcc version only
works for 32 bit values.
Generate wxJoystickEvent with the same fields under all platforms by
making the Linux and macOS versions follow MSW convention of using
"1 << N" for the changed button.
Add GetButtonOrdinal() accessor which can be used to retrieve just N.
Closes#18233.
There doesn't seem to be any point in storing pointers to wxBitmap or
wxIcon and storing the objects directly allows to avoid an extra heap
allocation and all the code dealing with freeing memory when replacing
or removing images from the list, making things much simpler.
Also use wxVector<> for storage instead of the obsolete and ugly
wxObjectList.
There shouldn't be any user-visible changes.
Cache labels for "Next>" or "Finish" button in wxWizard so that their
translations stay consistent throughout wizard's lifetime: previously,
this button could use a label in a different language if the currently
used translations have changed since the wizard creation, as this label
was recreated on every page change, unlike the other labels which were
only translated once in the very beginning.
Closes https://github.com/wxWidgets/wxWidgets/pull/1000
Under macOS colors can be patterns, then accessors for RGB values are useless, IsSolid returns true if the color can be expressed in RGB values at all.
Get rid of wxOSX wxImageList implementation as it was 99% identical to
the generic version and the non-identical parts should really have been
made part of the generic version too from the beginning.
Notably, use GetScaled{Width,Height}() in Add() method in the generic
version too now.
This is not necessary as wxIcon is implicitly convertible to wxBitmap
anyhow, so calling Add(icon) works using the existing Add(wxBitmap)
overload, and is actually harmful because of the wrong icon size check
in this function, which used physical bitmap size instead of the logical
(scaled) size.
Closes#18188.
We need to account for the scale factor under GTK+ (and, presumably,
under macOS) to compute the correct PPI value as it must use the number
of physical and not logical pixels.
Reimplement wxPopupWindow using WS_POPUP instead of WS_CHILD window in
wxMSW as the new approach allows using the controls inside the popup
normally, unlike the old one.
See https://github.com/wxWidgets/wxWidgets/pull/986Closes#18243.
