Commit 70e9dbd756 has fixed#18394 but unfortunately it also caused several other issues observed e.g. in #18540. Apparently wxComboCtrl doesn't fit well to the wxCompositeWindow framework - especially when wxCB_READONLY flag is set and there is no main editor control what is problematic for wxCompositeWindow implementation. At the moment it is more pragmatic to go back to the original wxComboCtrl concept as a plain compound control to fix the regression and try to fix#18394 in an alternative way.
Closes#18540.
See #18394.
This could result in infinite recursion in wxX11, as the test for the
new size being different from the old one which was supposed to stop the
recursion, failed there in case the new size was 0: as wxX11 can't use 0
size for the window, the actual size was always different and so we kept
sending size events to the parent, which kept resizing the toolbar etc.
It could be argued that there is a bug in wxX11 and that GetSize() must
return the same value as was passed to SetSize(), even if it was 0, and
this might even be correct, in theory, but it doesn't seem worth to do
it just to accommodate this weird use case, especially because resizing
the parent from the child shouldn't be necessary in the first place and
none of wxToolBar implementations in the other ports does it.
So just remove this code completely.
Closes#18554.
It doesn't seem worth having it when it's only used in a couple of
places in a single file, unlike GetHwnd() which is used in dozens of
places across entire wxMSW.
Override MSWGetFocusHwnd for wxSpinCtrl to focus the right subwindow.
So the correct window will be used in wxWindowMSW::SetFocusFromKbd and
the spin controls content will be selected on TAB key.
Under MSW allow override which subwindow will be focused for composite
windows which are implemented not as a set of wxControl (i.e. using only
Windows native controls).
This is not really an option as building requires it to be 1, so don't
make it one in setup.h/configure/cmake and just hardcode it as 1 for
compatibility.
Closes#18558.
Implicitly-declared 'constexpr wxDataFormat::wxDataFormat(const wxDataFormat&)'
is deprecated because 'wxDataFormat' has user-provided
'wxDataFormat& wxDataFormat::operator=(const wxDataFormat&)'.
For VS solutions, the DPI aware manifest is added as additional manifest.
For makefiles, the DPI aware manifest is included via the resource file.
Set the default DPI Awareness to per-monitor.
First two paramaters of ctors of wxPGProperty and its derivates are named
'label' and 'name' so wxDirProperty ctor should conform to this convention.
Close#18547.
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
This results in the toolbar being too small to show any items in it
in wxGTK and wxOSX, because the parent window size is still the default
small one and not the actual size it will be when shown, when the size
of the toolbar is first set.
And it seems completely unnecessary to do this anyhow, as toolbar is
resized by wxAuiManager in any case.
Closes#18218.
Carbon is not supported any more and defining m_overlayWindow, which was
only used by Carbon code, resulted in "unused private variable" warning
from clang.
We can't handle the accelerators (known as "key equivalents" in Cocoa)
in this function because it is called for the views in top to bottom
order, while wx semantics is for accelerators to be handled in the
accelerator table closest to the focused window.
So just remove this code and rely on accelerator handling happening in
wxWindowMac::OSXHandleKeyEvent() instead.
Closes#13937.
Remove caching of whether any of the children accept focus in
wxControlContainer as it can change at any moment under Mac, due to full
keyboard access being turned on and off (which can be done using
Ctrl-F7, i.e. easily, and so this might be something users actually do
and not just a theoretical edge case). This also incidentally fixes
caching of the wrong focusability state during window initialization,
when its children are not yet shown, as [NSView canBecomeKeyView:] used
for AcceptsFocusFromKeyboard() implementation under Mac, apparently
always returns false for hidden windows.
The behaviour under the other platforms should remain the same, but
AcceptsFocus() is slower now as it always has to query children instead
of being able to avoid doing it when we know that none of them accepts
focus anyhow. OTOH this only happens to the windows that don't accept
focus themselves and, at least at some moment, don't have any children
accepting focus neither, which should be quite rare and optimizing this
case doesn't seem to be worth the extra code complexity due to extra
preprocessor platform checks.
Closes#18089.
Handle these events in the menu itself first, then the window and only
then at the application level instead of falling back on the application
before searching the window for the handler.
This requires using the logic already present in the base class
DoProcessEvent() method, so make it protected to allow reuse.
Closes#4769.
Size grip in generic wxStatusBar is only supported in wxGTK as it's
drawn using GTK functions, but this is not really a problem as other
platforms either use native implementations (MSW, Qt) or shouldn't show
size grip anyhow as it looks non-native (Mac).
So just ensure we don't leave space for the grip if it's not shown,
correcting the change of 6c1b2b23cf.
Closes#18469.
This implementation suffers at least from 2 problems:
1. It doesn't support icons at all.
2. It toggles the checkbox when clicking on the text and not just on the
checkbox itself, as would be expected.
but it's still better than the current version which simply doesn't work
at all, i.e. can't be toggled in any way (and also doesn't draw itself
correctly when using dark mode under macOS 10.14+), so use it for now.
A better solution would be to fix the problem with ActivateCell() not
working at all (see #17746) and update the code to respect drawing in
dark mode.
Closes#17473.
Closes https://github.com/wxWidgets/wxWidgets/pull/904
Fixes to wxUIActionSimulator allowing the tests using it to work for
wxGrid in wxGTK.
And some improvements and bug fixes to wxGrid itself.
Closes https://github.com/wxWidgets/wxWidgets/pull/1609
Recent MSVS 2017 versions (15.9.x) as well as MSVS 2019 give warning
C4548 about "expression before comma having no effect" when including
standard CRT headers.
This happens because when building projects targeting 8.1 SDK, as the
IDE uses the hard coded 10.0.240.0 version of UCRT headers in this case
(see \Common7\IDE\VC\VCTargets\Microsoft.Cpp.Common.props), and the
headers in this version haven't been, and will never be, updated to
avoid this warning, as was done in later 10.0.x UCRT versions.
Fix this by explicitly disabling the warning in wx/beforestd.h, as even
setting the warning level to 1 for the standard headers somehow isn't
enough to suppress it if it's enabled.
This is always 0 for any still supported compiler, so remove the option
and configure checks for it.
Still define it as 0 for compatibility, just in case it's used outside
of the library.
We don't support MSVC 6 (__VISUALC__ == 1200) or eVC (1201) since more
than 5 years (see f4b80e5337), so it's
useless to keep code compiled only when this compiler is used.
On DC with a non-rotated coordinate system drawing a filled rectangle with ExtTextOut() Win API is faster than drawing a line with MoveTo()/LineTo() so on such DCs we can use ExtTextOut() to draw horizontal/vertical lines with solid colors and square ends instead of calling MoveTo()/LineTo().
See #18517.
This method is supposed to be overridden in the sub-windows of a
composite control (and is indeed correctly implemented in
wxGridSubwindow), but it doesn't make any sense to implement it in the
parent window itself.
This method was probably never executed (which is how the problem went
unnoticed for 10+ years since 760be3f7cb),
but it's still wrong to define it here, so remove it.
This is unnecessary as TAB navigation is not supposed to work between
wxGrid children and actually harmful as this resulted in SetFocus()
doing nothing, instead of setting focus to wxGridWindow, if the focus
was on wxGrid itself for some reason (this happened at least in the grid
unit tests and resulted in failures because the in-place editor didn't
appear as expected).
Apparently some existing code still used it, even though it only created
an object that could never be used for anything, so undo its removal in
bd09b4132d and deprecate it instead.
Unfortunately, this also requires changing wxTimerEvent::m_timer type
back to pointer, even though it should be a reference.
Setting WS_EX_COMPOSITED, as the base class version does, just results
in visual artefacts and is useless, as we turn on LVS_EX_DOUBLEBUFFER
already, if it's supported, anyhow.
So don't break the display if people call SetDoubleBuffered() in the
mistaken belief that it does something useful in this case.
