New line is not always marked by 2-character (\r\n) sequence. It can be
also 1-character (\r) for RichText controls or even no mark at all (for
wrapped line).
This reverts commit c4e1fb4ef9.
Last position is not necessarily the number of characters in the buffer,
rich edit controls still store the text using CR LF between lines, but
GetLastPosition() should return the position as if they used only LF to
be consistent with all the other positions in these controls and
changing this broke existing code passing GetLastPosition() to other
functions taking position.
There is a valid position after the last character of the text in
wxTextCtrl, e.g. position 0 in the empty control, so account for it and,
notably, don't return -1 from XYToPosition(0, 0) when the control is
empty.
This fixes a regression in a69ab2907c.
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...
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.
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.
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.
This virtual method is implemented in wxWindowBase class only when
wxUSE_DRAG_AND_DROP==1, so it should be re-implemented in the derived class
wxWindowMac also only when wxUSE_DRAG_AND_DROP==1.
Several functions of wxTextEntry and wxTextCtrl call to
gtk_entry_get_text_length() API to determine the length of the text in
GTKEntry. This API is available since GTK+ 2.14 so we have to implement
a fallback method for older GTK+ versions.
Dedicated function GTKGetEntryTextLength() is implemented in wxTextEntry
and exposed through its interface because it is also used in wxTextCtrl.
wxPen::SetDashes() is poorly designed, making it possible for different
wxPenRefData objects to point to the same dash array. This allows two wxPen
objects to appear to be equal after modifying the array and setting it on
the second pen (the drawing sample does this). So testing for equality is
not enough to determine that SetPen() can return early.
