- 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 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
The previous commit fixed never exiting the event loop in GUI Mac modal
loops but at the price of breaking it for Mac console applications as
Dispatch() never returns for them if there are no more events.
Finally, just don't call Dispatch() at all here, just as it wasn't done
until 9caa3d5d8e and keep only the changes
sufficient for dispatching the pending events and making CallAfter()
work in console applications.
Changes of 9caa3d5d8e resulted in never
exiting modal event loops as wxCFEventLoop::Pending() always returns
true. While this is certainly wrong on its own, for now just avoid using
it and check the return value of Dispatch() instead to allow the modal
event loops to terminate again.
Wrong pointer was used to initialize wxDataViewItem (apparently since
always, i.e. this function could never have been used successfully...).
Closes#18132.
Apply parts of the changes of 34c5aaa769
done in the common code to Mac-specific wxCFEventLoop too.
This is not ideal as we really should reuse the same common code here,
but for now it's better than nothing as previously pending events were
just not dispatched at all in console Mac applications, meaning that
CallAfter() from worker threads never executed.
Owner-drawn buttons with multiline labels were always centered.
Fix this by handling their alignment explicitly when drawing them, as
::DrawText() doesn't do it for multiline strings.
Closes#18131.
It's not possible to map the scaled integer coordinates to the exact
destination location. The inaccuracy can be (mostly) avoided by shifting
the DC origin instead. Also fixes handling of non-zero logical origin.
See #18129
Allow using positions in the entire int range for window positions under
MSW, and not just those in (slightly less than) short range, that are
supported by the native API.
Closes#4262.
Closes https://github.com/wxWidgets/wxWidgets/pull/779
VarSizedStruct buffer had a too small size in Unicode build as it forgot
to multiply the name length by sizeof(TCHAR), resulting in overwriting
memory on the stack after it when calling SymFromAddrW().
Closes#18127.
This file was added in 4d524cdd0e a long
time ago but doesn't seem to have been ever actually used for anything
and is outdated, e.g. contains LSRequiresCarbon=true, which shouldn't be
used any longer.
Remove the file itself and all references to it.
This setting is important for some functionality provided by
wxNSApplcation and most importantly without the setting all samples
where only shown scaled on high DPI displays.
Notice that it was already present in src/osx/carbon/Info.plist.in which
is used for the samples in autoconf build.
Closes https://github.com/wxWidgets/wxWidgets/pull/743
When determining if a tool is hidden, it takes the width (or height) of
the overflow sizer into account -- but when tools are overlapping, this
is 0. By setting and getting the minimum size of the overflow sizer, the
actual size of the overflow button can be used.
Closes#17960.
Closes https://github.com/wxWidgets/wxWidgets/pull/799
Multiplying 2 float values is promoted to double, which is then narrowed
to float when initializing CGPoint with it, resulting in errors in C++11
build.
Fix this by initializing the CGFloat variable, which doesn't uniform
initialization, to the correct value instead, as this also seems more
clear ("height" is the height at which the strike is drawn).
Closes https://github.com/wxWidgets/wxWidgets/pull/793
Save both the normal window geometry and its maximized position instead
of saving just its current position. This fixes restoring geometry of
the maximized windows as previously they were always restored on the
primary monitor, as their original position was lost.
Use the native {Get,Set}WindowPlacement() functions for a MSW-specific
wxTLWGeometry implementation to achieve this.
Closes#16335.
Previously, TLW geometry was implicitly defined as just its position,
size and the maximized/iconized state by wxPersistentTLW code. This
already wasn't enough for wxGTK which added the decoration sizes to the
geometry being saved/restored, but this had to be done using conditional
compilation, which was not ideal. And it didn't allow using an entirely
different geometry representation as will be done for wxMSW soon.
Change the code to use wxTLWGeometry class defining the geometry, as
used by the current port, explicitly and move wxPersistentTLW logic into
it, as wxPersistentXXX classes are supposed to be very simple, which
wasn't really the case.
Also provide public SaveGeometry() and RestoreToGeometry() methods in
wxTopLevelWindow, which can be useful even to people not using
wxPersistentTLW for whatever reason.
There should be no changes in behaviour so far.
The changes of 8d02384792 only modified
the generated file without updating the file it was generated from and
so were lost during the next regeneration.
Back-propagate them to the correct file to prevent this from happening.
See https://github.com/wxWidgets/wxWidgets/pull/782
