The callback used with CreateDialogIndirect() must return INT_PTR, which
is 64 bits under Win64, not LONG, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
The callback must return LRESULT, which is 64 bits under Win64, not
int, which is still 32 bits.
This fixes a gcc8 -Wcast-function-type warning and might fix a real bug
in Win64 build too.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
This parameter wasn't used anyhow and casting wxWndProc or m_oldWndProc
to WXFARPROC just resulted in gcc8 -Wcast-function-type warnings.
Get rid of them by not passing the window proc to this function at all.
Don't use the deprecated since Win16 (!) and doing nothing
MakeProcInstance() and fix the signature of DDECallback() which was
actually wrong in Win64 build but the problem was hidden due to the
casts done inside and outside MakeProcInstance() before.
Remove this macro and fix the signature to actually conform to the real
callback one.
This also fixes another gcc8 -Wcast-function-type warning.
Put the code implementing object arrays, i.e. arrays owning pointers to
the objects, into wxBaseObjectArray<> instead of _WX_DECLARE_OBJARRAY
macro.
Also simplify WX_DEFINE_OBJARRAY() by leaving only the definitions of
functions creating and destroying the objects in it (they have to be
there and not in the template itself to allow using template with
incomplete classes).
Add wxBaseSortedArray<> template instead of putting all the code inside
_WX_DEFINE_SORTED_TYPEARRAY_2 macro.
There should be no changes, but the code is now easier to read and
modify.
Dramatically simplify dynamic array macros by keeping only the
implementation previously used in wxUSE_STD_CONTAINERS case and dropping
the other one, as we can use the std::vector-based implementation on top
of our own wxVector<>, which is available whether wxUSE_STD_CONTAINERS
is 0 or 1.
This allows to get rid of tons of ugly macro-based code without breaking
compatibility.
These events are unexpected and inconsistent with the other platforms,
including GTK+ 2, so make sure we don't send them during the
destruction.
Closes https://github.com/wxWidgets/wxWidgets/pull/821
Don't repeat the same check for !defined(WXUSINGDLL) many times.
No real changes, this is just a simplification (which should be viewed
with "git diff -w --color-words" to see how little has really changed).
MSVC users can simplify their projects by prepending
$(WXWIN)\include\msvc to the compiler include directories, which results
in automatic including the build-specific setup.h and linking all
required wxWidgets and system libraries.
This worked only for the default multilib builds but not for monolithic
builds where wxWidgets libraries are created and named differently.
This patch allows the users (by defining wxMONOLITHIC=1 in their
project) to use it also for monolithic builds.
Somehow this compiled with the previous gcc versions (as well as MSVS),
but a static_cast from an integer wxUIntPtr type to a pointer HANDLE
type is obviously invalid and a reinterpret_cast is needed here.
This fixes compilation with g++ 8.
Include gdk/gdkkeysyms.h from wx/gtk/private/gtk2-compat.h as it must be
included before it for the compatibility header to define the new names
for the key constants even when using old GTK+ versions.
The definition of macros min and max in include/wx/msw/wrapgdip.h
b/include/wx/msw/wrapgdip.h was clashing with the new bessel functions
that use std::numeric_limits<T>::min/max.
So #include <cmath> before #include <gdiplus.h> and use using
declarations of std::min and max instead of macros.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
Using memset() with objects of (non-trivial) class type results in a
-Wclass-memaccess warning with g++ 8, so avoid doing this.
Add a Clear() method allowing to do the same thing without breaking
encapsulation.
These objects are never copied, and if they were, the default
(compiler-generated) copy ctor would do the same thing this explicitly
defined copy ctor did, so just remove it.
wxListHeaderWindow event coordinates don't need to be adjusted, as it's
positioned at (0, 0) of its parent window anyhow, but wxListMainWindow
events do need to be adjusted to use the parent window coordinates, as
it's the only window that should be seen by the outside code -- and also
for consistency with the native MSW version.
This corrects the changes originally done in
651d7a1ff8
See #18133.
- Functions that set wxMONO_* vars need to set them in parent scope, from macros instead of functions (functions would need grandparent scope)
- Fix a conflict with xml library linking Mono which made core include the wrong png headers
- Fix setting of NOPCH on windows to go through the wx_lib_compile_definitions instead of target_compile_definitions so it carries to monolithic build
- Allow use of precompiled header in MSVC via calling wx_finalize_lib(mono)
- Introduce wxMONO_NONCOMPILED_CPP_FILES to deal with set_source_files_properties only applying within the current CMakeLists file
- Fix demos building against monolithic library by using wx_exe_link_libraries instead of target_link_libraries (similar to what the tests already do)
Closes#18074
The minimum width will always be equal to the current size of the parent window (from wxGetClientRect).
As a result, controls using wxHeaderCtrl can never be shrunk (e.g. using SetSizeHints).
Problem is visible when a wxDataViewCtrl gets a lower DPI. The new minimum size is equal to the current size.
The entire control is hidden until the dialog is resized.
This seems to be caused by (recent changes in) the wxPersistentManager.
This is fixed by populating the frame before restoring persistence.
(as is described in docs/doxygen/overviews/persistence.h.)
When the wxBitmapComboBox is empty, GetBitmapSize() returns size -1,-1.
Images can not be scaled to this invalid size. Use the size of the imagelist
instead.
When using an out of source build, the files are not in the default wxWidgets directories.
Also search in the current directory, parent directory and sample sub-directories.
Closes https://trac.wxwidgets.org/ticket/18118
