Adding Custom View to Swift macOS Cocoa project

Elements Silver
1

Couple of issues, Fire doesn’t seem to understand @IBDesignable, is there some doc I should be reading plse?

Secondly, adding a CustomView in IB, setting it’s class to a class that’s subclassed from NSView, results in an error at runtime - view not found error, using NSView instead. Checked out the xib xml and it’s named OK. Restarted Fire, it now runs (some cache issue?), but fails …

Getting Exception of type ? on thread … EXC_BAD_ACCESS

Debugger highlighting the line starting ‘override’

@IBObject public class ScoreView: NSView {

override func draw(_ dirtyRect: NSRect) {
    super.draw(dirtyRect)

    NSColor.whiteColor.setFill()
    NSRectFill(dirtyRect);

}

}

Also found this not working, probably due to swift and sdk versions, 10.13 is listed - the following works in Xcode set for 10.13, but Fire says no such static member when referring to CGColor.white

class GraphView: NSView {

override func draw(_ dirtyRect: NSRect) {
    super.draw(dirtyRect)
    
    self.wantsLayer = true
    self.layer?.backgroundColor = CGColor.white
}

}

Conclusion is there must be something fundamentally different about the setup between Fire and Xcode I’m not understanding.

2

Alan,

sorry for the delay, been traveling all day Wednesday and yesterday.

I’m afraid that’s a feature we cannot support, because (as far as I’m aware) not depends on Xcode building the Objective-C/Swift code for the control itself, at designtime, so that cannot work with Elements generated binaries (or source). At best, we could make @IBDesignable a no-op attribute, so you could add it to your code w?o any effect, Elements side, but could then try and open the same file isn Xcode as well (assuming git has no other Elements-specific dependencies…

Make sure your view class has the @IBObject attribute — otherwise it’s name might get mangled by the compiler (eg prefixed with a namespace), and then Cocoa runtime cannot find it. Could that have been it?

Hmm, alternative it could have bene a build caching bug, yes, but I cannot imagine iow it would happen (the reverse would be more likely, am outdated XIB in the binary, but in tour case, it seems more like the new XIB got in, but the new class did not — weird. Can you reproduce this with specific steps?

Can you send me a full test-case for that? That code looks fine on its own…

yes. the “problem” is that Apple Swift puts the nice Cocoa APIs thru a process they call “Grand Rename” that takes just ab out every name and changes it according to rules that — while in theory well-defined — seem arbitrary and don’t always match their specs. Chances are they are applying some different logic to CGColor (which is just a opaque struct, on Cocoa level) to add the color members such as white there. I’ll need to investigate whats (not) happening.

[quote=“tipper258, post:1, topic:16744”]
Conclusion is there must be something fundamentally different about the setup between Fire and Xcode I’m not understanding.

In general, our compiler compiles against the Cocoa Objective-C classes that make up the native Cocoa frameworks — same level as Objective-C does. And we jump thru a whole bunch of hoops to get most of Swift;'s mappings available to our compiler as well (Burt also keep the old/good/nice names). Apple’s Swift compiler really does not target the Obhjective-C runtime but has a whole meta-layer of extra stuff on top.

You could argue that Silver (and our other three languages) are more native Cocoa that Apple Swift is.

3

Hey Marc,

Thanks again for comprehensive help. I’ve been working on this in Xcode too to get a base version of the Java converted across but even that’s proving challenging in the ‘native’ platform tools. I’m going sit down and do a formal class on Cocoa on macOS, then I’ll revisit. I though understanding other UI frameworks well would help, but a combination of the documentation being more reference than comprehension oriented, and so much out of date articles out there that I’m finding it much harder than I thought it would be.

I was even tempted to abandon and just continue refining the 35,000 line Java/Swing code base to survive another new years, but not giving up yet!