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.
Don't explicitly set the default icon size, this isn't really necessary
and just prevents things from working correctly if the child frames use
icons of a different (especially bigger) size.
Still try to use the icons of the standard size by default, but let
wxAuiNotebook adjust to bigger icons if this is what we have.
Don't define GetIcon(), GetIcons() and SetIcon() at all as the base
class already implements them and just keep SetIcons(), which can now be
marked as overridden as it's inherited from wxTopLevelWindow via
wxTDIChildFrame.
For testing, allow using wxAuiMDI{Parent,Child}Frame in the sample.
This change also shows that the AUI classes are now sufficiently
compatible with the standard ones for switching to them to be almost
trivial.
This method is confusing as it's not used for implementing Show(), which
is the usual naming convention when both Foo() and DoFoo() members
exist, and gives no clear indication about what does it really do.
Just call wxWindow::Show() directly instead.
Also create the wxAuiMDIChildFrame window hidden from the beginning,
instead of creating it in a visible state and then hiding it.
There doesn't seem to be any reason for overriding DoSetSize() and
DoMoveWindow(), so just stop doing it.
Notice that this was already changed for wxGTK many years ago in
a94476deb9 and there is no reason to use
different code wxGTK and other ports.
Make it easier to use AUI-based MDI child frame class instead of
normal wxMDIChildFrame itself by inheriting it from the same base class.
This also allows to get rid of duplicate stubs in wxAuiMDIChildFrame.
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
