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
The changes between 1010 (which was already considered equivalent to
1002) and 1011 don't seem to affect wxWidgets and the library compiled
with g++6 can be used from the application built with g++7 without any
problems.
There doesn't seem to be anything wrong with just showing the popup menu
in this window itself and this avoids the need to do any coordinate
adjustments, which didn't work correctly for the menus shown over the
header window after the previous commit (and hadn't worked correctly for
the menus shown over the non-header area before it).
See #18133.
The position was off by the header height due to a missing translation
between wxGenericListCtrl and wxListMainWindow, in which the menu is
actually shown, coordinates.
Closes#18133.
The default alignment of the text in wxSpinCtrl was changed to "right"
in 7e4952db83, which added alignment
support (see #10621), but this made it inconsistent with the native
up-down control under MSW and, perhaps more importantly, with spin
controls created from XRC as the default style was never modified there
and did not include wxALIGN_RIGHT.
Resolve this inconsistency by reverting to left-aligning the text by
default.
The horizontal static line was added to separate the button from the
child window when visible, but this didn't seem very useful and looked
bad and was inconsistent with the native GTK+ implementation as well as
similar controls commonly used under MSW (wxOSX already disabled the
static line use).
Just remove it to make things simpler and better looking.
Closes https://github.com/wxWidgets/wxWidgets/pull/804
