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)
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”
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) 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).
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
You’re right, I was commenting my experiments with ObjC and, since I tried that language, I always thought Swift was just a name for a new ObjC version.
I also agree my comment here wasn’t informed, but assumed/deduced.
Posted thoughts can be wrong (as long as they are not lies), that’s one way to learn
No worries… and yes, Swift and Objc while have some things in common, are otherwise VASTLY different. I attempted to crack ObjC a few years ago, and grew too frustrated with it… However, Swift (to me) was as easy to learn as Xojo was. But then again, I have learned, used and forgotten more programming languages than a lot of people have even heard of
Note : NEITHER of these statements apply to ObjC, with DOES require tons of pointers, and manual memory management
It does depend on your skill level and what you’re trying to accomplish. It’s like the difference between a manual transmission and automatic transmission… Maybe not, because a manual transmission is fun…
For a lot of tasks the only time you need to worry about memory management is when you need to store an object, when you allocated the memory for an object, or you use a Core api Create routine.
I personally favor Objective-C over Swift, I think some of that comes from having more experience with Objective-C. I also use swizzling to persuade existing objects to do what I want, which I understand is not possible with Swift.
A lot of people also hate how verbose Objective-C is, but personally I think that is one of it’s strengths. I can look up code form from 20 years ago and understand it, and if that API has been deprecated, the selectors are so verbose that it helps me to find the replacement.
Objective-C uses dynamic tables to loop up method pointers from a mutable list. Swift is/was fixed.
Swizzling basically allows you to alter the table, so instead of having the drawRect (for arguments sake) routine call the function in the actual object, you can redirect the call to a different object or “module”.
It’s how I patched a couple of bugs in the Xojo framework, by redirecting their functions to code I am in control of.
A bit like Xojo’s AddHandler function, but for everything, events, methods and even wrapped properties.
Note : NEITHER of these statements apply to ObjC, with DOES require tons of pointers, and manual memory management
Objective-C has had ARC (Automatic Reference Counting) in XCode for quite a while. You can turn it on/off as you like (even file-by-file). Of course, you don’t get that if you’re using declares from inside Xojo, then you do have to manage everything yourself.
Perhaps my opinion, but not just mine.
