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.
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.
wxScopedPtr is referred in wxSVGFileDCImpl declaration, but corresponding
header file is not explicitly included. This can break the compilation if
wxScopedPtr declaration is not included by chance by another module (e.g.
is taken from translation.h but it is not effective when wxUSE_INTL==0).
MakeConfigFileName() is declared as a pure virtual function in the base
class wxStandardPathsBase and has to be implemented in the derived class
wxStandardPaths.
This fixes compilation when wxUSE_STDPATHS==0.
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.
Check if character position is not past the line.
When calculating (x,y) for given character position there is necessary
to take into account that for multi-line control each line (but last one)
is ended by 2-character end of line mark. Each character of this
2-character mark has a different position in the text buffer but is mapped
to the same (x,y) coordinates.
When calculating character position for given (x,y) there is necessary
to verify if passed coordinates are sane and return error status (-1) if
not. y-coordinate has to be in the range [0..numLines-1] and x-coordinate
cannot exceed the length of the text in the given line.
Apparently there is no native API to retrieve such information in a simple
way so all calculations have to be done with raw text stored in
the corresponding control(s).
Closes#4146.
See #17811.
The sample requires wxUSE_EXTENDED_RTTI to be enabled, and that is correctly signalled
in the source files. Just avoid the header flooding the output with errors.
Closes https://github.com/wxWidgets/wxWidgets/pull/525
* Removed BOM.
