Speaking of drawing, I have a very serious problem wit NSView. I
cannot call frame() nor bounds() on instances or subclasses and
get a valid NSRect. (same goes for NSWindow frame()).
I had similar problems when working with NSAttributedString and
NSRange, because NSRange from Chocolat was still 32 bit. After
fixing this, it all worked perfectly. The parameter to drawRect,
which is a NSRect as well contains correct values. So it seems to
me that the NSRect struct declared as is should work just fine.
I am trying to implement drawRect in an NSView subclass (in the
Portmidi example, KeyboardView). Everything works fine,
NSBezierPath drawing methods etc., but I cannot call this.frame()
nor this.bounds() from within that method without triggering a
runtime segmentation fault. Often I see this in the crash log as
Sometimes there is other stuff, but always indicating a memory
I have not the slightest idea what could be the problem here, it
most likely is not a threading issue, as drawRect is anyway
called on the main thread, and usually one only has crashes if
one tries to update widgets from background threads, which of
course is not allowed in Cocoa, as the AppKit is not thread safe.
I just checked back, for any widget it fails. You can easily
reproduce it by e.g. opening the SimpleWebBrowser example and add
in applicationDidFinishLaunching (this is a good point, because
all the UI element should be ready):
NSRect backButtonFrame = backButton.frame() ;
NSLog("frame %f %f %f %f", backButtonFrame.origin.x,
For custom components, if this won't work, it is almost a deal
breaker for using Cocoa through D. This is quite a setback, all
the rest so far encountered is working so beautifully.