Use wxScopedCharBuffer as we only need the buffer in the current scope.
This avoids a buffer copy done by wxCharBuffer which could be a
significant pessimization for large buffers.
Also don't call strlen() unnecessarily, we already know the buffer
length, so just use it.
This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
This could happen if the code calling SetValue() was in a handler
invoked in response to a keyboard action as our insert-text signal
handler believed that it was called in response to this key in this
case, even when it wasn't the case.
This extends the changes of def8247c61
to WriteText() to DoSetValue(), thus fixing the same problem in
SetValue() and ChangeValue() too.
But the question of why do we have two so similar, yet different,
functions, resulting in having to fix the same bugs twice still remains
unanswered...
Remove the already described sizers from section Other Types of Sizers. Remove "See ..." sentences which are unnecessary when the class documentation is already linked right above. Also fix a typo in a sizer name that prevented doxygen linking to the class.
Remove references to concrete GUI-building programs. Such references are not necessary not to mention that most of the referred programs have not been maintained for a long time.
List of flags in the CreateButtonSizer sizer was unnecessary, some of the values were not valid flags for the methods and comment descriptions for most values did not make much sense in the given context. The section was therefore removed and the method is mentioned in the newly-added part about wxStdDialogButtonSizer.
Sizer types not mentioned in the overview before were added, the rest of changes was mostly adding @c and such.
Passing long argument to "%c" printf format specifier was correctly
flagged as invalid in 64 bit Unix builds where long != int.
Fix this by just making the "keycode" variable int in the first place,
there doesn't seem to be any reason whatsoever for it to be long and
this allows us to get rid of a couple of existing casts instead of
adding yet another one.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
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.
