NSTextView does not natively show a focus ring by default, and it is
extremely rare thing to do in native applications.
Don't do it in wxTextCtrl either.
NSTextView doesn't display focus ring by default, which is why wxOSX
did draw it manually, but this behavior can be overriden since OS X
10.3 with NSView.focusRingType property.
The HITheme-based rendering suffered from a number of non-nativeness
issues:
- didn't respect macOS 10.14+ accent colors
- not animated as the native focus ring
- subtly different shape of the outline
- noticeably different outline shape on macOS 11
Remove NeedsFocusRect() and associated workaround for manually drawing
focus ring inside NSTextView (i.e. multiline text controls). This
private interface was only used for wxTextCtrl and nothing else, so
this shouldn't have any impact elsewhere.
Provide API for dealing with m_lastKeyDownEvent instead of using it
directly and extend it to avoid sending duplicate events for keys which
are mapped to multiple selectors, such as Ctrl-O with the default key
bindings.
Closes https://github.com/wxWidgets/wxWidgets/pull/1928
Don't use NSLayoutManager lineFragmentRectForGlyphAtIndex:effectiveRange
when NSTextView is empty, as this result in debug error messages.
Fall back to using the font height in this case instead, as this seems
to be the only thing to do in this case.
Closes#18793.
This is consistent with the current behaviour of GetSizeFromTextSize()
and the behaviour of GetBestSize() before the changes in this branch.
This is still not consistent with the behaviour of the other ports, but
this will be addressed later, by replacing the currently hardcoded 5.
Note that calling usedRectForTextContainer: here was apparently wrong in
any case because we were not sure to have already performed a layout and
we should have had a call to ensureLayoutForTextContainer: before it to
make it actually work. However, this made it work "too well" because it
then correctly returned potentially very big sizes for the text controls
containing a lot of text, which is not what we need here, as explained
in the comment added by this commit.
This reverts the changes of 63bcc669d8 (fixing setting initial value
under osx_cocoa for single line text controls, 2009-10-01) and fixes the
problem which this commit probably tried to fix in a different way,
using the same approach as in 98f5315405 (Don't set initial label in
wxNativeWindow on OS X, 2016-04-29) as the real root of the problem was
that the text set in CreateTextControl() was overwritten later when the
label was set from SetPeer().
This change means that the text is now set correctly before SetPeer()
calls SetInitialSize() call, which makes it possible to set the correct
initial size based on the initial text, as will be done in later
commits.
It also makes Cocoa port more consistent with iOS one, as a nice side
effect.
We can't handle the accelerators (known as "key equivalents" in Cocoa)
in this function because it is called for the views in top to bottom
order, while wx semantics is for accelerators to be handled in the
accelerator table closest to the focused window.
So just remove this code and rely on accelerator handling happening in
wxWindowMac::OSXHandleKeyEvent() instead.
Closes#13937.
This is always 0 for any still supported compiler, so remove the option
and configure checks for it.
Still define it as 0 for compatibility, just in case it's used outside
of the library.
NSCell of a single-line wxTextCtrl cannot be just switched
to the single-line mode because apart from restricting layout to a single
line this also effectively blocks processing of the Return key.
To restrict the contents of the cell to a single line we need to replace
in wxTextEntryFormatter every new line character with space (this simulates
what is done when NSCell works in native single-line mode).
Closes#18183.
Closes#18179.
Closes#18101.
See #12693.
When wxColourDialog is shown, any changes to the colour selected in it
apparently result in broadcast messages to all currently visible text
controls, which was unexpected.
Block the changeColor: message to prevent this from happening.
Closes https://github.com/wxWidgets/wxWidgets/pull/830
If the text in the control doesn't end with a new line,
last valid position is just past the last character in the
the last line.
But if it ends with new line, last valid position
is located at the beginning of the next virtual (empty) line.
So, this case has to be also taken into account in determining
whether position is valid or not.
Take into account that last valid position is after the last character of the text.
This applies also to empty controls for which XYToPosition(0, 0) should return 0.
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.
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.
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.
Emit wxEVT_TEXT_{COPY,CUT,PASTE} from NSTextView methods, calling native
implementation if not handled. NSTextField-based wxTextCtrl is not
supported, because it doesn't have the copy:/cut:/paste: methods.
For some reason known only to Apple, NSSecureTextField allows pasting text
into it using its standard context menu, but not using the standard Cmd+V
keyboard shortcut. Moreover, apparently the control does something special to
disable it because pressing Cmd+V does result in a call to
-[NSSecureTextField control:textView:doCommandBySelector:], but with a dummy
"noop:" selector.
Detect this specific situation and check if we're called while handling Cmd+V
event and, if this is indeed the case, do paste the text into the control.
While it could be argued that this changes the platform behaviour, it seems
very hard, if not impossible, to imagine a situation in which this would be a
problem while not being able to easily paste into password fields is
definitely a real usability bug.
Don't make the controls with wxTE_DONTWRAP (a.k.a. wxHSCROLL) style
"infinitely" wide, but just "very" wide to allow alignment still work in it.
See #17529.
Allow the user to customize smart quotes and dashes substutions on OS X
and also provide the OSXDisableAllSmartSubstitutions() method for
disabling them all at once.
This reverts ill-advised commits
c07523734f and
8d42890df4 that disabled native OS X
behavior of substituting dashes and quotes with typographically correct
characters if the user has this feature enabled.
This was a bad idea for two reasons:
1. It made wx applications behave non-natively, and thus be worse, in a
highly noticeable area.
2. It made it impossible for applications that want to behave correctly
to restore the native behavior, because once
setAutomaticDashSubstitutionEnabled or
setAutomaticQuoteSubstitutionEnabled is called (as wxTextCtrl
constructor does), it's no longer possible to obtain its original,
default setting.
It's not better to disable native functionality by default, it's better to
be native and make customizations possible. wxWindow API exposes access
to the native control and if an application desires to disable
substitution behavior, it can easily do so from user code.
See also #186 and #241.
Disable ASCII quotes substitution with "more typographically accurate"
symbols, just as we already do it for the dashes substitution.
While disabling this unconditionally might not be perfect, it's better than
unconditionally leaving this enabled (and this is on by default since OS X
10.9).
Closes#15705.
Closes https://github.com/wxWidgets/wxWidgets/pull/241
This makes wxTextCtrl behave like the native text controls and, in particular,
makes it select its entire text when it gets focus (incidentally, this is also
how it behaves under the other platforms).
Closes#9521.
This makes the text control match the other platforms as well as making it
usable for entering compiler or command line flags for programs.
Closes https://github.com/wxWidgets/wxWidgets/pull/186
Allow automatically converting lower-case letters entered into wxTextCtrl to
upper-case equivalents. Provide generic fallback and implement the method
natively for all the major platforms.
Also update the text sample to show it in action.
According to the documentation, insertText: argument is either NSString
or NSAttributedString. The latter is not a subclass of the former, yet
the code assumed the argument is always a NSString. This caused the
following exception:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason:
-[NSConcreteMutableAttributedString characterAtIndex:]: unrecognized selector sent to instance
Fix this by checking for NSAttributedString and extracting plain string
from it.
