I’m going through my old notes, bug reports, and workarounds for Cocoa Text Areas. Here’s what I’ve found so far…
The Good:
Issues with TextArea.SelTextBold (etc) not returning the text style at the insertion point, when .SelLength is 0, seem to be fixed
The bad:
Issues with TextArea.SelTextBold (etc) not changing the style of the selected text seem to remain : Note you can typically set a style such as Bold, but you can never un-set it. This is described in <https://xojo.com/issue/22559> There are some workarounds, but they are not good. I’d consider this a “ShowStopper” type bug.
<https://xojo.com/issue/23696> SelectAll doesn’t trigger .SelChange : This is still happening, (and the case hasn’t even been reviewed, even…). Since there is a decent workaround for this, it’s not as critical.
Other folks - what’s the status of your TextArea bugs?
<https://xojo.com/issue/17242>
This one seemed to be fixed but it still does not set the text color for text added after the style change.
If the order is changed so that it adds the text and then selects it, SelTextColor works.
'this does not work for cocoa builds (works with carbon or win32)
TextArea1.SelTextColor=RGB(255,0,0)
TextArea1.SelText=“Some Text - this should be red…”
'this works
TextArea1.SelText=“Some Text - this should be red…”
TextArea1.SelStart=0
TextArea1.SelLength=Len(TextArea1.Text)
TextArea1.SelTextColor=RGB(255,0,0)
I’ve also noticed that the TextArea is not happy with line endings in strings added via the .Text property when it has been manipulated in some way first in code. The Text encoding of the string is probably “nil” after I have built the text and when these are added to the text area I see diamond symbols instead of getting line endings. I can fix this by setting the encoding first but I’ve never needed this before:
newtext=DefineEncoding(newtext,Encodings.UTF8)
<https://xojo.com/issue/24435> Inconsistent behaviour of Return key when entering text in TextAreas & TextFields: not serious, just annoying
<https://xojo.com/issue/24431> (‘Verified’) Changed font property of a TextArea does not update immediately in the IDE’s Window Editor: not serious, just annoying
<https://xojo.com/issue/24429> (‘Closed (Not Reproducible)’ but the bug is still there) LineHeight and LineSpacing property settings are not reflected in the IDE’s Window Editor, although OK at runtime: not serious, just annoying
<https://xojo.com/issue/22342> (‘Verified’) Symbol fonts are not working in a Cocoa TextArea: not serious until you need to use these fonts!
<https://xojo.com/issue/22051> (‘Verified’) TextArea alignment is not working for right or centre alignment: but it can still be set at runtime
<https://xojo.com/issue/8913> (‘Verified’) MouseCursor settings are not respected in a TextArea: this is the show-stopper for me as I have not found a workaround that works for Cocoa
<https://xojo.com/issue/25304> Cocoa: TextArea cursor overrides the app.mousecursor or me.mousecursor (redundant with #8913)
Perhaps not a bug report, it may be working as intended, but then a feature request:
<https://xojo.com/issue/25543>Assigning text to a StyledText object resets all styles to default
You should always have correct encodings on strings you’re treating as text (as opposed to a bag of bytes). The Xojo Cocoa framework is more strict about this because Cocoa itself always expects valid NSStrings when doing things like setting a control’s text. If the Xojo Cocoa framework is passed a string that has no encoding or isn’t valid in the encoding provided, we provide a fairly graceful fallback:
If the string is marked as UTF-8 but isn’t valid UTF-8, we attempt to parse it as UTF-8 and replace any invalid sequences we find with the Unicode replacement character.
If the string had no encoding or it was otherwise invalid, we treat it as ASCII and replace anything non-printable with the Unicode replacement character. Due to an oversight on my part, newlines are counted as non-printable. However, it’s proven useful in finding strings that have no encoding and I haven’t been particularly motivated to change it.
Prior to the addition of this fallback path, we would pass invalid strings to Cocoa and crash (or get exceptions or other fun behavior).
[quote=6434:@Jonathan Ashwell]Perhaps not a bug report, it may be working as intended, but then a feature request:
Feedback Case #25543Assigning text to a StyledText object resets all styles to default[/quote]
I think this is working as intended, but I haven’t had a chance to go and verify that.
Joe - regarding newlines. Since in Cocoa, EndOfLine is now CHR(10) rather than CHR(13) - does this have implications for how we pass strings into textAreas? Does Cocoa honor both ascii 10 and 13 or should we use one rather than the other? (The issue being that strings entered in the IDE seem to have CHR(13) line endings).
In cocoa, if you right-click a textArea, you get a ton of options on the contextual menu. Is there any way to override these options? For example, my app doesn’t support sideways text, so being able to disable “Layout Orientation/Vertical” seems like an important thing to do. Can we do this perhaps via Declares?
Similarly, my app has its own Font/Color system - is there a way to disable the “Show Fonts…” / “Show Colors…” options?
Undo/Redo : it seems that TextAreas manage their own undo/redo stack? If so, is there a way I can override that behavior? (My app has its own multi-level undo/redo system, and having two separate undo/redo stacks is confusing).
In cocoa, if you right-click a textArea, you get a ton of options on the contextual menu. Is there any way to override these options? For example, my app doesn’t support sideways text, so being able to disable “Layout Orientation/Vertical” seems like an important thing to do.[/quote]
You can implement the ConstructContextualMenu event and return True. Whatever menu you built will be the one that’s shown.
If you make your own contextual menu, this shouldn’t be a problem. Otherwise you could try sending the NSTextView the setUsesFontPanel: message. I don’t recall all of the details, but I think it does a bit more than disable the font panel.
It does, but you can override it by implementing EditUndo/EditRedo menu handlers in a TextArea subclass or the window itself.
If I could make a small addition to the lists above:
<https://xojo.com/issue/42> (‘Verified’) Setting visibility of TextArea scrollbars at runtime does not work. I was noticing this again just now jumping between Cocoa and Carbon builds. The same text in a Cocoa TextArea takes more space vertically compared to Carbon, so I need the scrollbar for Cocoa but not for Carbon.
[quote=6459:@Richard Corlett]If I could make a small addition to the lists above:
<https://xojo.com/issue/42> (‘Verified’) Setting visibility of TextArea scrollbars at runtime does not work. I was noticing this again just now jumping between Cocoa and Carbon builds. The same text in a Cocoa TextArea takes more space vertically compared to Carbon, so I need the scrollbar for Cocoa but not for Carbon.[/quote]
I can say for certain that this won’t happen for 2013r1 as it seems to be a feature request. However, it ought to be doable via declares.