Some versions consist of four parts with the last part being called the
revision or build number. wxVersionInfo is now able to save such a
fourth number.
Add another compatibility implicit constructor to allow the existing
code, directly passing XPM data to various functions that used to take
wxBitmap or wxIcon and now taking wxBitmapBundle, to work.
Closes#22566.
Don't change the window size automatically if the application handled
wxEVT_DPI_CHANGED event to allow it to choose a better size than what is
suggested by MSW itself.
Closes#19152.
Use this macro where possible and simplify the checks in a couple of
places where it isn't (because we're checking for an exact glibc
version).
No real changes.
Make wxINVERT logical function work in at least some circumstances with
wxGTK3/X11 and use this to make wxSplitterWindow and wxSashWindow
separator visible during resizing.
See #22546.
Closes#16890.
HasAlpha() was already available in most of them, now ensure that it's
present in all of them, especially as it has a reasonable default
implementation.
UseAlpha() was only present in wxMSW and wxOSX and still remains only
implemented there, but provide at least a stub for it elsewhere as well
to avoid problems such as that of #17393.
See #22545.
Closes#17397.
We don't need to store this string, we don't need it after the ctor.
Also change the default value of an argument of wxString reference type
to be a wxString, not a const char*.
While there is no real harm in keeping them, it still seems better to
tell people that they're not needed.
Don't put them inside WXWIN_COMPATIBILITY_3_0 for now, however:
considering how late in 3.2 development this deprecation comes, it seems
better to wait until after it and then use WXWIN_COMPATIBILITY_3_2
instead.
Neither of these methods was actually ever used after the changes of the
last two commits (and they hadn't been used when not using wxGTK even
before), so don't force the user-defined model classes to override them.
Also stop using them, as the stub versions don't return correct values
any longer.
Still keep the virtual functions in the base class for compatibility
however as it doesn't cost us much and avoids breaking the existing code
using "override".
This is implemented in Cairo and CoreGraphics renderers only, but this
is still useful as these renderers are used on the platforms where wxDC
wxINVERT logical function is not supported and this composition mode can
partially replace it.
Calling TransferDataFromCustomControls() in custom panel destructor
suffered from two fatal flaws:
1. It happened whether the dialog was accepted or cancelled, while
we're only supposed to call this function when it's accepted.
2. It was done too late, when the customization hook itself could
have been already destroyed, as it only has to live until ShowModal()
returns but doesn't have (and typically doesn't) survive wxFileDialog
itself.
Fix this by adding TransferDataFromExtraControl() and calling it
explicitly when, and only if, the dialog is accepted.
This fixes accessing invalid stack memory (thanks ASAN!) under GTK and
Mac and allows to remove the ugly workaround from wxMSW code, which can
now also just call TransferDataFromExtraControl().
Arithmetic conversions on operands of different enumeration types
are deprecated in C++20 so we need to explicitly cast the operand
to the compatible type.
Closes #22505.
After the changes of the previous commit, calling SetupBitmaps()
preemptively is not necessary any more, as it's called in any case just
before showing the menu, so remove the calls to it to simplify the code
and even make it slightly faster (at the cost of slowing it down before
opening the menu, but this needs to be done in any case to avoid
reintroducing the problem fixed by the parent commit).
Ensure that all derived classes have these functions and let them to
avoid defining them if they can just use the default implementation,
which was the case for most ports.
Also move m_bitmap to the base class from the derived ones.
No real changes.
These two ports were the only ones to use something other than m_bitmap
for wxBitmapBundle storing the item bitmap, rename it for consistency
with the other ports and to allow moving this field into the base class
in the upcoming commit.
No real changes.
When using common dialogs, because IFileDialog-based implementation is
not available either at compile- or run-time, this function needs to be
called while the extra controls still exist, i.e. before ShowModal()
returns, so do it from CDN_FILEOK handler.
Move the code that called it previously into the new MSWOnFileOK() for
consistency with the other callbacks.
Closes#22521.
Derive wxSimplebook from wxNavigationEnabled<>: this is needed for at
least wxGTK and shouldn't do any harm even for the platforms where TAB
navigation worked even without it, such as wxMSW.
Closes#22517.
This function doesn't have to be a member, so remove it from the header.
No real changes yet, but this will make it simpler to change it in the
upcoming commits.
We don't need to declare CGFloat and NSInteger in our own headers when
we can just use double instead of the former in our public headers and
the latter wasn't used in them at all.
Note that this requires including CoreGraphics/CoreGraphics.h from the
private wxOSX headers as several of them do use CGFloat, which wouldn't
be defined otherwise.
wxOSX doesn't build in 32 bits since quite some time and it doesn't seem
worth fixing this, so just ensure that we give a clear build error in
this case instead of multiple and less clear errors further down the
build process.
Also remove the now unnecessary checks for __LP64__ from wxOSX code.
It doesn't seem to be useful and wasn't really specified in 2 out of 3
existing calls to this function and was probably wrongly specified in
the remaining one, so just remove it for now, it can always be added
later if we decide what exactly should it do.
Forward the events from the actual wxControls used in the generic
implementation of wxFileDialogCustomize to wxFileDialogCustomControl so
that they could be handled by the application code binding to them.
Add implementation of the new file dialog customization API in terms of
the old one for the non-MSW ports (or even wxMSW if IFileDialog can't be
used for whatever reasons).
Just map wxFileDialogFoo to the corresponding wxFoo.
The hack with creating a dummy dialog just to get the size of the extra
controls is only used in wxMSW, so move it to MSW-specific file from the
common code.
To allow doing this there, add CreateExtraControlWithParent() helper,
which is still not really used anywhere else than in wxMSW, but at least
doesn't do anything particularly ugly and doesn't really penalize the
common code for wxMSW sins.
No real changes.
Creating a text with a label is a common operation and can be
implemented to look slightly better than AddStaticText() followed by
AddTextCtrl() without a label when using IFileDialog.
Inherit wxFileDialogCustomControl from wxEvtHandler to allow Bind()ing
to events on it and use this to handle wxEVT_BUTTON and wxEVT_CHECKBOX
in the sample.
And inherit from IFileDialogControlEvents in wxMSW code to actually
generate these events when they happen.
wxFileDialog::SetCustomizeHook() can be implemented in terms of
IFileDialogCustomize in wxMSW, which means that it can be used with the
new style dialogs shown by IFileDialog, unlike SetExtraControlCreator(),
which could only be supported when using older style common dialogs.
Add support for a few different controls and wxMSW implementation, more
controls, generic implementation and the documentation will be updated
later.
Also update the sample to show the new API in action and allow toggling
between using it and the old API for testing.
