I’m implementing a custom keyboard for iOS. It consists a UISearchBar the user can use to filter the “keys” they can use to type. When the search button is used, I call [searchBar

On 8/13/18 6:55 PM, Andy Lee via Groups.Io wrote: Thanks, that did help. I think the root of the problem is that my app is not totally a normal Cocoa app. I am in the process of

I got curious and created a scratch app to fiddle with. I called [NSApp runModalForWindow:] and was surprised to see that even though the dialog was demonstrably modal (clicking on the window behind

"While the app is in that loop, it does not respond to any other events (including mouse, keyboard, or window-close events) unless they are associated with the window. It also does not perform any

On 8/13/18 6:00 PM, Andy Lee via Groups.Io wrote: Interesting. The window does have a little red close button, and once the dialog is closed one can quit normally, so maybe I

I forget the tweak to do this -- I think it has something to do with using your own run loop. I'm pretty sure I've done what you describe. If I can find how I'll post it here, but maybe the run loop

On 8/13/18 5:04 PM, Bill Pitcher wrote: It's not a sheet, just a window being operated with -[NSApplication runModalForWindow:].

Not sure it is possible, modal means just the controls on sheet are actioned. Normally if you’re in a sheet and you want the App to Quit you add a Button that Quits. I think you can give the button

I'm trying to enable the Quit menu item while a modal dialog is running, is that possible? My window controller implements the terminate: action, and has a validateMenuItem: method, but

Yeah, I don’t know why either, but I had the same experience of it suddenly doing that with no apparent cause.

Well duh. Thanks Quincey, that was it. I use so little C++ myself now that I’ve honestly never seen this before. It’s still a bit of a mystery why just the presence of the added framework in the

Are you sure it’s really failing? Historically, the security framework is known to use C++ exceptions internally for flow control. If you have an Xcode C++ exception breakpoint set, it stops, but

Hi all, I have a long-standing app project/workspace that embeds several sub projects, which build as embedded frameworks. It all builds and runs fine as it should. I add a new framework subproject

Hi Bill: Thanks very much for the explanation and especially links to where the old docs are. I remember the loos leaf docs and the excellent Inside Mac books and the docs you linked to. Just

Sorry, I'll try and be more Objective. Working back in Aqua 10.0 there was no documentation, LOL and we had to read the message names and headers to get an understanding of this NextStep puzzle. With

Hi Bill. Thanks for your (Swift) reply <grin>. You may be correct in how the flow works. Mind you I have not found any documentation to support it; can you point me to some? I was basing my assumption

Hi Peter, I think you have the flow here a little confused. func applicationShouldOpenUntitledFile(_ sender: NSApplication) -> Bool lets the App know if there is going to be an Untiled Document,

Good idea… However I just did this: 1. created a new document project 2. added to AppDelegate.m - (BOOL)applicationShouldOpenUntitledFile:(NSApplication *)sender { // Use this method to decide

I can’t swear to it, but I’m pretty certain this is a result of state restoration. Assuming you had at some previous point created an untitled window, then state restoration will recreate it at

macOS Yosemite 10.10.5; Xcode 6.4 In testing a vanilla Document app I tracked down what may be a bug in Cocoa. I expected that the app would not open an untitled file