The config file uses the wxWidgetsTargets file to find all the libraries that
can be linked to.
It supports checking for components (e.g. base, core, aui, gl) and fails if a
requested component is not found.
Set the version compatibility to SameMinorVersion (when CMake supports this),
because different minor wxWidgets versions (3.0 and 3.1/3.2) are expected to
break API.
Because the default libraries are named like wx::wxname, create an alias that
is just called wx::name. CMake older than 3.18 does not support creating an
alias to non-global imported targets, so manually create a library with the
same properties.
The wxWidgets CMake build only builds the Release and Debug configurations, but
when creating a (MSVC) CMake project it also contains MinSizeRel and
RelWithDebInfo configurations. By default these seems to use the Debug
libraries, causing build errors. Map them to the Release libraries instead.
Also create a wxWidgets_LIBRARIES variable that can be used to link with, so
users can keep using the same variables from FindwxWidgets.
The headers are installed in 'include/wx-3.1/', so also use this in the INSTALL_INTERFACE.
Determine wxINSTALL_INCLUDE_DIR only once and reuse it in install.cmake.
Use wx_install macro so install is only used when wxBUILD_INSTALL is set.
The install.cmake script has a check for wxBUILD_INSTALL, so don't use it there.
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().
As NSOpenPanel is a subclass of NSSavePanel, we can define "sPanel" in
any case, whether we're working with "Save" or "Open" dialog, and doing
this allows reusing this variable instead of writing another ugly cast.
Also use static_cast<> rather than C-style casts.
No real changes.
Define "wasAccepted" variable and use it instead of testing "returnCode"
several times and setting another "result" variable, which is actually
not needed at all.
No real changes.
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.
Add the directory only to the build interface, not to the install
interface. INTERFACE_LINK_DIRECTORIES can't use paths that are prefixed
in the source (or build) directory.
Closes#22524.
Allow selecting between the "default" and "simple" providers for now, we
might want to extend this to allow user-defined providers in the future.
Closes#22515.
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).
Set up popup menu bitmaps after executing wxEVT_MENU_OPEN handler, so
that any changes to the menu item bitmaps done in it are taken into
account, as this only happens when SetupBitmaps() is called.
Closes#22530.
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.
Move the code freeing the global wxConfig object from wxApp::OnExit(),
which is called only after running the main loop, to wxApp::CleanUp(),
which is always called.
This fixes memory leaks when not running the main loop at all, as e.g.
when showing a modal dialog instead of doing it.
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.
We need IFileDialog and not an IFileOpenDialog when creating a generic
file dialog, all the code had been already updated to only use the
former and not the latter, except for CoCreateInstance() itself which
still always asked for the latter, resulting in a failure when trying to
obtain IFileOpenDialog from a "Save" file dialog not providing it.
Also update some log messages to use the generally correct interface.
See #22521.
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.
The control still needs to be repainted after calling
RecalculatePositions(), so don't reset the dirty flag in it and do it
only in RecalculatePositionsAndRefresh() instead.
Arguably, EnsureVisible() should call the latter function itself, but
don't change this for now and just correct the regression caused by the
changes of d8fe06891e (Avoid bool argument in wxListMainWindow::
RecalculatePositions(), 2021-08-06).
Closes#22511.
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.
Without doing this, such applications (e.g. wxTaskBarIcon-based ones)
don't get any events on startup and wxApp::OnInit() doesn't get called.
See #22508.
Closes#16156.
Some things that seem too obvious to say apparently are not, so do say
them explicitly, as having the leftover from the template in the bug
reports is really confusing.
LPARAM is a signed 64-bit type, and OBJID_CLIENT is defined as ((LONG)0xFFFFFFFC),
so converting to LPARAM will sign-extend and the comparison will always fail.
Fixed by comparing as DWORD, as the Microsoft documentation recommends.
