Yes, unfortunately, that is the correct behavior. This is described

At the runtime level, properties are implemented as getter and/or setter methods. The `getter=` syntax just lets you rename the getter method. It doesn’t affect the property name. It seems a little

I just replicated this in a sample and ran a short test to see what the results are. @interface MyObject : NSObject @property(strong, nonatomic, readwrite,getter=getRootAPIData) NSDictionary

In the iOS app that I’m working on now, we have a problem that I’ve never seen in my years as an iOS programmer. While we have a 99.7% crash free user experience, what does crash is weird as

There are other NSPanels, that’s not sufficient. What I came up with was to find an array of visible windows before calling orderFrontStandardAboutPanel:, find an array of visible windows

True, but this is a little freeware side project, and I didn’t feel like polishing that much.

Where is it documented that it's wrong? I don't think it's actually wrong. iMovie, for example, has com.apple.iMovieEvent declared both as an exported UTI and as a document type. Besides, it *does*

Well, this is kind of wrong. CFBundleTypeExtensions and LSTypeIsPackage should not be specified in the document type when you’re using an exported UTI. I don’t really recall their presence

I have a file type all set up in my target's Document Types and Exported UTIs as

The About window has no name - the title is blank. it would seem that a more interesting way to do the would be to use the [NSWindow windowNumberWithOptions:] method, which does return an array of

Ah, fair point! How hard is it then to make your own About box? To bring it up instead of the prebuilt one is a very small change to the ‘About’ menu item, to target a different method. Making

Well, its class is NSPanel rather than NSWindow - is it sufficient to just hide / show all NSPanels in the app's window list when you're deactivated / activated? Alternately, you can look at all

The standard About panel doesn’t exist in a nib, it’s synthesized by AppKit.

In Interface Builder, just check the “Hides on Deactivate” checkbox for the panel. That should do it… have you tried it? —G

How can I find the window produced by -[NSApplication orderFrontStandardAboutPanel:]? (I’d like to hide the window when my app deactivates.) I know it’s somewhere in the array -[NSApplication

Jens, Thanks here’s what I have, Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application

It’s in the crash report near the top, like this: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 That long hex number is the

Jens, Thanks for pointing out this out. That makes sense since presumably in the frames above we are in calls resulting from the stream removing itself which would be hard to explain if it were

Not exactly. In frame 4 the NSInputStream has been messaged successfully, which almost never happens if it’s already dealloced; you almost always get a crash in objc_msgsend in that case. Instead

I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease? Thread 8 Crashed: 0