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 last "message":


Sometimes there is other stuff, but always indicating a memory corruption.

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, backButtonFrame.origin.y, backButtonFrame.size.width, backButtonFrame.size.height) ;

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.

Reply via email to