NSTextView - Tabstops?

I cannot get tabstops defined for an NSTextView no matter what I do.

It SAYS they are being set, but they never change

I just need ONE set, not dozens of specialized paragraphs.

This code seems to be the standard internet Answer…

 func setTabStops() {
     let p = NSMutableParagraphStyle()
        p.defaultTabInterval = 8 * self.editor$TextView.parent!.charWidth
        p.tabStops = []
        self.editor$TextView.defaultParagraphStyle = p
        self.editor$TextView.typingAttributes = NSDictionary(object:p, forKey:NSAttributedString.Key.paragraphStyle as NSCopying) as! [NSAttributedString.Key : Any]
    }

self.editor$TextView is the NSTextView needing to be set
if at any time in the program I query self.editor$TextView I get the values that I would expect

but what I get is the “default” tabstops (12 of them) after which is inserts a unwanted carriage return (this is an expected behaviour based on various articles)

Do you have a visible ruler? I seem to vaguely recall this has something to do with it…

No… I do not… .just a plain rectangular NSTextView

Heck… I can’t even get the Font to stick, unless the App inserts Text before the user types, which also isn’t optimum…

but even if I add one it still shows the default 12 tabstops…

SOLVED… what a pain that was

func setTabStops() {
        let p = NSMutableParagraphStyle()
        p.defaultTabInterval = 8 * self.editor$TextView.parent!.charWidth
        p.tabStops = []
        var x : CGFloat = CGFloat(p.defaultTabInterval)
        self.editor$TextView.defaultParagraphStyle = p
        var z = self.editor$TextView.parent!.zTextAttr
        z[NSAttributedString.Key.paragraphStyle] = p
        self.editor$TextView.typingAttributes = z
    }

Had to take the desired Font Attributes (zTextAttr) and append the tabstop data, then assign that to the “typing attributes”

One reason I’m not ready to leave Xojo…

There are compromises both directions.

Xojo cans a lot of stuff for you , but because of that you are limited in the ultimate flexibility… To extend Xojo you need to dive into DECLARES (or plugins) , which adds a level of complexity equal to what you complained about above. Not to mention that there are STILL limits on how those can be applied.

Swift also cans alot of stuff for you, but what Swift does that Xojo does not, is to expose almost the entire infrastucture of each control. This has both a pro and a con. The pro being it allows for nearly infinite control, the con is the learning curve on some of this is rather steep… But the results are much better, and you only need to slide down that curve once.

As an example, the project that this is part of is a full blown text editor, and the core custom control (similar to “Custom Edit Field” for Xojo) is less than 1000 lines of code, while CEF is an XML file over 40,000 lines long (and yes I realize there is more overhead in that file format)…

So I am not telling you to stay with Xojo, nor am I telling you to leave, I am saying however that Swift (for me) offers the flexibilty as well as challenge that Xojo cannot (barring using an OS other than macOS/iOS or tvOS)… [tvOS by the way, Xojo cannoot and probably will never do]

I tend to not agree completely.
Take the question about Tabstops, or others you asked recently, for example. Those are already addressed by Xojo (as you mentioned).
So, the basic/core stuffs are taking less time with Xojo.

Then, if you want something more, yes declares are the way to go and they are sometimes complex; but you already did most of your app prior to this point.

Obviously, the path with all made using declares is more consuming than using Xojo.

I get your point about having the entire controls available; I prefer RAD, still. Just a matter of opinions.
(and don’t get me started about worthless semi-colons and punctuations and other things making the code unreadable/overcomplicated) :wink: Perhaps my opinion, but not just mine.

Of course you are entitled to your opinion , and I’m not trying to change it.

I don’t understand this statement you made however…

don’t get me started about worthless semi-colons and punctuations and other things making the code unreadable/overcomplicated

Swift does not require semi-colons… They can be used to put multiple statements on a line to increase readablitiy (totally optional, and not available in Xojo), but required? Not at all. Perhaps the ONLY thing that takes some getting used to is curly brackets…

Agreed. On the other hand, that flexibility would be added by the promised Interops.
And yes, it’s amazing to see that Apple basically delivers an already full blown text editor with NS/UITextView (which you have to customize still for the individual purpose of course). Having all that available without declares or plugins could bring Xojo a bit more on par with the mentioned solutions.

I haven’t actually tried Swift, only seeing pieces of code around the Internet (and tried Objective-C years ago, but not done much with it).
I agree I shouldn’t have tied “semi-colons” and this thread, because it talks about Swift; I should’ve had mentioned only “punctuation”.
Pointers, memory management,… I stay with Xojo because I don’t deal with things that looks not important to me (read: which I can do otherwise, more simply).

Again, my preferences.

I am not knocking your preference… you are as entitled to it, as I am to mine.
Just be sure your comments are informed is all I would ask… since your comments are much more oriented to ObjC than to anything with Swift… And in those regards I agree, I dislike ObjC very much… but with Swift, pointers are used in much the same way (and as often) as Xojo uses them, and memory management is much the same… as transparent in Swift as it is in Xojo… Note : NEITHER of these statements apply to ObjC, with DOES require tons of pointers, and manual memory management

1 Like