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

I stopped on that breakpoint as well, and it doesn't help other than point out that it is indeed a bug. Changing the bound value should not cause editing to end. I just want to know if it's been fixed

IIRC, there is another method that you can check, with something like didEndEditing something like that. I remember having to go through several on iOS to find what I wanted.

Since we finally were able to move up to 10.13 (printing company, historically slow to change), I've noticed that text fields in views and in cell-based table views now exit editing as soon as any

Dear all, Thanks for your replies. It turned out it wasn't due to a zombie pointer, though I did turn on that setting to check (hadn't thought of that as a possibility for this problem). After quite a

Oh - here you go. It's in the scheme's Run > Diagnostics tab even back in Xcode 6: https://code.tutsplus.com/tutorials/what-is-exc_bad_access-and-how-to-debug-it--cms-24544 - Jon

As Quincey said, it looks like you've got a zombie pointer that's now pointing to an NSWindowGraphicsContext instead of the original, now-deallocated NSSnapshotBitmapGraphicsContext. Turn on zombie

I suggest that you start with most mundane possibility, that this is a zombie object. My guess is that this is one of those crashes that can happen when breaking down a UI, such as when a window is

Hi all, Can anybody advise on the following exception/crash that I am encountering? The issue is: The problem is that as far as I can see this is something internal to AppKit, and I’m not sure what

This is a Swift usage question. I am working on a family of UI objects which share some common behaviors. Having done several, it is time to refactor (for all of the obvious reasons). I would like to

I will file a bug. The reason for using Xcode 9 is that there's a library that depends on the GNU stdc++ library, and the effort to bring that into Xcode 10 is too much to bother at this point. I

It could only be an issue while using the debugger; is there a reason for not using a more modern Xcode? Regardless, you should definitely file a bug report, including a sysdiagnose, your log from

I should add that it's a window in my app, not in Xcode. Running outside the debugger, it appears to be fine, but the exception stops me being able to check on some other issues related to the