Sockets returned by wxSocket::Accept() are non-blocking by default and
the only way to use them safely in worker threads is by switching them
to the blocking mode by calling SetFlags(wxSOCKET_BLOCK).
However this didn't work correctly since at least 2.8 days, as turning
wxSOCKET_BLOCK on didn't unregister the socket from the event loop, with
which it had been registered on creation. Fix this by doing this now,
which ensures that the main thread doesn't get any notifications about
the socket if it's used, in a blocking way, in a worker thread.
Note that making the new socket blocking after accpeting is still pretty
inefficient and pre-creating the socket as blocking and using
AcceptWith() is still preferable, but at least it does work now.
Closes#12886.
In addition to unblocking and registering the socket, also support using
this function to make the socket blocking and unregistering it from the
event loop, if its flags include wxSOCKET_BLOCK.
This was already half-done by wxMSW, which took wxSOCKET_BLOCK presence
into account in its implementation, but not by the Unix implementation.
Now do it under all platforms, as this will be useful for switching a
previously non-blocking socket to blocking mode.
Finally, rename the function to better reflect what it really does.
See #12886.
It should still be possible to use DoEnableEvents() to disable events
for blocking sockets and this can be useful if a previously non-blocking
socket became blocking due to a SetFlags(wxSOCKET_BLOCK) call, so adjust
the fix of e18c8fd29a (see #17031) to
avoid calling EnableEvents() for blocking sockets instead of ignoring
them in DoEnableEvents() itself.
Also add an assert checking that we never try enabling events for
blocking sockets as this still doesn't make sense and so shouldn't
happen.
No real changes yet, but this is necessary for the upcoming commits.
See #12886.
Fix bug with not being able to update wxTaskBarIcon under MSW after a
DPI scale change or [dis]connection of another monitor using different
DPI: this resulted in "TaskbarCreated" message being sent by the system,
which we handled by trying to create the taskbar icon again. However in
this case, recreating it failed, presumably because it still existed, as
modifying the existing icon still worked.
Change the handle of "TaskbarCreated" to try both adding and updating
the icon, as it seems that we can't be sure whether we still have it or
not when we get this message.
Refactor the existing code to specify the operation to perform when
calling the new DoSetIcon(). This actually makes things slightly simpler
for it, as it doesn't need to update m_iconAdded inside it any more.
Closes#18588.
There is absolutely no good reason to do it and it resulted in
silently truncating all the string formatted using "%s" to their first
65535 characters when using our wxPrintf() implementation.
Closes#18586.
Actually allow using wxWebVieWIE-specific methods for setting the
emulation level.
Make it possible to include wx/msw/webvieW_ie.h by removing inclusion of
the private headers from it, which was in turn achieved by moving all
the implementation details into a private class.
See https://github.com/wxWidgets/wxWidgets/pull/1647
Ensure that the entry is always (just) big enough to show any value
valid in this spin control.
This also ensures that GetBestSize() doesn't need to be overridden to
use GetSizeFromTextSize() any longer as the best size will be determined
correctly by GTK itself.
For GTK2, get the "inner border" the same way GTK does it. And for GTK3,
provide an actual implementation. Also, don't return a wxPoint for a size.
See #18567
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.
Previously, the first monitor was created instead and while it was often
also the primary one, this wasn't always the case.
In particular, this makes wxGetDisplayPPI() always return something
reasonable instead of returning (0, 0) when the first monitor is not the
primary one, as expected by plenty of code, including our own printing
sample, which divides by the values returned from wxGetDisplayPPI()
without checking if they're zero.
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.
This caused wxTextCtrl to become to high at higher DPI.
It was added to fix appearance of wxSearchCtrl at high DPI. Remove an unneeded
FromDIP there too, so it gets the same height as a normal wxTextCtrl.
And centre the textctrl inside the searchctrl.
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
