This message now appears even in the (default) release builds as __WXDEBUG__
is always defined, so it needs to be at least somewhat understandable by
normal users, even if it remains primarily targeted at the developers.
Also remove __WXDEBUG__ checks in this function, this is a left-over from the
pre-3.0 debug mode.
Get rid of ugly wxDynamicCastThis()s in wxMSW wxControl code and add a
new virtual method overridden in wx{Tree,List}Ctrl instead.
Also stop comparing the font with wxSYS_DEFAULT_GUI_FONT, there doesn't
seem to be any good reason to set this particular font for these
controls neither.
In addition to simplifying and de-ugligying the code, this commit
incidentally fixes -Wnonnull-compare warnings in this code from gcc6
too.
This doesn't seem to make any sense as this function is always called
with non-null "*this" reference from wxPixelData dtor and results in
-Waddress warning from gcc 6.
In wxStdDialogButtonSizer, keyboard navigation order through the buttons
should be the same as the order they are positioned in the sizer regardless
of the order the were created or added to the sizer.
Closes#17940.
Under MSW calling UnblockAndRegisterWithEventLoop() for blocking sockets
is not only useless, but actually harmful when the socket is used from a
worker thread (which is the common case for blocking sockets), as it
means that the main thread will be receiving notifications for the
socket events and modifying the socket object while it's being used from
the other thread, resulting in data races and general brokenness.
This is similar to e18c8fd29a for Unix
sockets.
Closes#17937.
wxSocketManager::Install_Callback() and Uninstall_Callback() are only
called for successfully created sockets, so there should be no need for
these checks and there are none in the Unix version.
This doesn't work, as non-blocking sockets implementation requires
dispatching events generated by them, which is only possible from the
main thread event loop, and it's better to be upfront about it rather
than failing mysteriously later.
This is similar to the previous commit, but for active FTP connections.
wxSocketServer was also created directly in this case, without using
wxProtocol ctor, so wxSOCKET_BLOCK must be explicitly specified when
creating it from worker thread, just as it was already done in
d421373c2e for the other connections and
in the previous commit for passive FTP ones.
See #17937.
This extends the changes of d421373c2e
to the case of passive FTP, which created wxSocketClient directly and so
didn't use the correct flags when used from a worker thread.
See #17937.
Building samples one by one has become a significant pessimization
nowadays, when multicore machines are much more common than single core
ones, so get rid of the shell loop which built the samples one by one
and use make targets to let make build as many targets at once as
desired.
Closes https://github.com/wxWidgets/wxWidgets/pull/536
When WM_ENDSESSION was received by the application, the wxApp object
itself was shut down by calling OnExit() on it before all the TLWs were
destroyed, which could be completely unexpected as during normal
shutdown the order of events is exactly the reverse.
In practice, this resulted in crashes in any application whose main
window close event handler or dtor touched wxTheApp in any way (e.g. to
save any configuration in the global wxConfig object destroyed by
wxApp::OnExit()).
See #9590 (sorry for missing the point before, ATS).
Rewrote wxOSX radio groups-related code reusing the code which works on
wxMSW and which seems to provide more rich functionality (supports adding
radio as well as no-radio items) and to have known bugs fixed.
The ranges of all radio groups are stored in wxMenu itself instead of
storing the information about the radio group an item belongs to in
the item itself - see 89511b4268.
Closes#14213.
Closes#17568.
When wxMenu contains radio groups and a new item (radio and non-radio) is
being added to the menu, data describing exisiting groups have to
be updated accordingly. Because adding radio and non-radio items has
a different impact on the groups, adding non-radio items has to be handled
separately. (The main difference between adding radio and non-radio item is
that when a radio item is inserted inside the group this group is extended,
but for non-radio item the group is split into two subgroups.)
While selecting wxBitmap with colour depth > 1 bpp into wxMemoryDC there is
no need to convert its format to ARGB regardless of the current
interpretation of the alpha channel values in the bitmap. If original
bitmap was marked as a RGB one (with alpha channel being ignored), it
should retain this format to avoid confusions.
Closes#16309.
Avoid calling gtk_window_set_geometry_hints() when the window can't be
resized anyhow, this doesn't seem to be necessary and results in
warnings like the following when using Gnome:
gnome-session[xxx]: Window manager warning: Window 0xxxx (Minimal wx)
sets an MWM hint indicating it isn't resizable, but sets min size 198 x
154 and max size 268435454 x 268435454; this doesn't make much sense.
Closes https://github.com/wxWidgets/wxWidgets/pull/529
The vertical scrollbar position could be updated (at least wit wxGTK) to
not show the last item any longer, after deleting the previously last
item, which was very annoying from the user point of view as the focus
was visually lost.
Avoid this by explicitly calling EnsureVisible() to prevent this from
happening.
Apparently various text wrapping modes are not supported natively by
NSTextView (apart from word wrapping which is used by default) and
non-default wrapping has to be implemented in the custom code.
To wrap lines at any character, NSLineBreakByCharWrapping style should be
applied at any text change to the entire text stored in NSTextStorage
associated with NSTextView. This is done in DoUpdateTextStyle() method
which is called from controlTextDidChange() when text is modified by
the user, or SetStringValue() and WriteText() when text is set
programmatically.
Aside from just being the proper thing to do, this fixes scrolling with
GTK3 when not using overlay scrollbars, where size events are somehow being
generated during scrolling.
See #17915
Under wxGTK wrapping for single-line controls is explictly disabled (see
wxTextCtrl::GTKSetWrapMode), under wxMSW wrapping is not supported, so for
the sake of consistency also under wxOSX single-line control shouldn't
support wrapping and vertical scrolling.
Closes#12693.
Wrap styles are not applicable to the single-line control and radio box
to select these styles should be disabled when single-line control is
active.
It looks that it was intended to implement this feature with
TextPage_WrapLines constant and OnUpdateUIWrapLinesCheckbox handler so we
can reuse these elements.
