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.
This breaks Mac build by default and shouldn't be done. In fact, Cairo
should be used only optionally under MSW and Mac, where it's not always
needed, so add a new configure option to request it.
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.
The code in the example showing how to create a new event class
confusingly used several names for the event type.
Fix this and also prefix the name of the new event type with "EVT_" to
match wxWidgets convention for naming event types.
Also explicitly mark the parts that are not needed if only Bind() is
used for event handling.
Closes https://github.com/wxWidgets/wxWidgets/pull/1586
A just created control shouldn't be considered modified, so reset its
modified state in Create().
And add a unit test checking that IsModified() really behaves as
expected.
Closes https://github.com/wxWidgets/wxWidgets/pull/1652
We don't need it any more, just define individual tests as independent
test cases.
This required using some other pointer instead of "this" in one of the
tests, but it doesn't really matter which pointer we use there anyhow.
No real changes.
Don't scale, or even copy, the font object unnecessarily in the common
case when the font scaling factor is 1.0 anyhow.
No real changes, just make the code slightly more efficient and also a
bit more concise after the changes of the previous commit.
Respect the system font scaling parameter (e.g. "Fonts->Scaling Factor"
in Gnome Tweaks, "Force font DPI" in KDE System Settings or
GDK_DPI_SCALE environment variable) when drawing text using wxFont.
This ensures that generic widgets have their text scaled appropriately
to be consistent with native widgets.
Closes https://github.com/wxWidgets/wxWidgets/pull/1635
This is unnecessary, this header should always be available, so it was a
waste of time to check for it at best and, actually, this broke the
Cygwin build under AppVeyor as configure didn't find the header somehow,
even if compiling the code using it works perfectly well.
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
Trailing spaces and tabs are invisible, so the string shouldn't be
truncated (possibly losing some printable characters that could have
been displayed) just in order to show "..." instead of them.
Verify that we have exactly as many offsets as expected, both in the
case when the string terminates with a (lone) ampersand and when it
doesn't, instead of checking that it's one or the other without caring
in which case we're.
No real changes, but this seems slightly cleaner and avoids questions
about the expression "s.length() - 1" when the string is empty.
The old code didn't work correctly in the presence of TABs in the string
(without wxELLIPSIZE_FLAGS_EXPAND_TABS being used), as their width is
elastic and so simply subtracting the width of the ampersands didn't
work in this case and could result in ellipsized string being longer
than the maximum available width.
Fix this by using a different approach and computing the widths of the
actually shown string and then just inserting extra entries into the
array of widths to match the invisible ampersands positions.
Previously we added the extent of the text to the preferred size of a
spin button with 0 digits, but this didn't account for the fact that the
control still reserved enough space for 3 digits in this case, and so
the returned size was always too big than the required size by the width
needed to show 3 digits.
Fix this by directly asking for the size required to show the number of
digits corresponding to the given text size.
Note that ideal would be to provide GTK API at wx level directly, i.e.
allow to just specify the number of digits instead of the text extent.
But we still need to fix the already existing GetSizeFromTextSize()
anyhow, so do this for now.
See #18568.
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.
The full size includes the borders and the return value of this function
might not actually be fully visible if we use it, as it can fit into the
full width but not the client width. And at least under MSW this
resulted in the ellipsized label being wrapped, which was completely
unexpected, especially if the second line of the control was not visible
at all as it seemed that the last word simply disappeared.
Closes#18573.
