I have what seems to be a simple operation to perform, but it crashes. I have a custom view which includes an NSTextView called textView. In the mouseDragged(with:) function in my view subclass, I

I thought this was answered earlier. Implement this in your app delegate // MARK: Open File (UTI support) /// process files give to us via "Open With..." /// /// - parameter sender:

Jonathan, Thanks for the solution of sending events to perturb the main runloop. With a little googling, I adapted your solution as follows… Cheers! double delayInSeconds =

> Do you suspect that throwing them on their own queue that you made would be an easy way to solve that? In terms of my own issue, the work items I'm dealing with are GUI-related so their natural home

Nice observation, Jonathan. Do you suspect that throwing them on their own queue that you made would be an easy way to solve that? I’d try it out myself, but am not in the best location to do that

This sounds very similar to problems I have encountered myself. Issue 1: GCD callbacks are part of an autorelease pool, but you can't rely on it getting drained in a reliable manner, so wrap your

It is a standard GUI MacOS app. No special options. It runs in user space like any other user focused Mac app. To be clear, when I say background, I mean it’s menubar is not the menubar being

What background options have you enabled in the app? I admit that I am unfamiliar with Mac policy on background apps and only ask with iOS background.

We have an app that handles incoming server connections. For each connection it opens a window that shows the activity of the connection. When the client is done the window closes. When the

Same as it ever was — just implement the -application:openFile: method in your app delegate. You also need to edit your Info.plist to include the document types your app knows how to open. To my

for archive sake… As is often the case with my problems, it lay between the keyboard and the seat. Answer: check the filename before making it into a

My guess is that it remembers what the first responder was before, so resigning a first responder would return the responder to the previous one, like popping a value from the the stack. I guess

Alex Zavatone via Groups.Io wrote on 21/4/19 12:16: That doesn't work, either. I was trying to force it bottom-up (I thought that the next responder would automatically be made first), but it seems to

Sorry if this is too late, but isn’t there a resignFirstResponder that you could call on the text field? Cheers, Alex Zavatone

Hi Folks, I will dispense with a rant about the eroding freedoms and the pains of sandboxing. My problem is finding a correct (App Store approval) method to enable drag and drop to the App

Thanks, that was it. John Jeremy Hughes via Groups.Io wrote on 18/4/19 12:55: -- John Brownie Mussau-Emira language, New Ireland Province, Papua New Guinea Kouvola, Finland

I think you should be calling (NSWindow) makeFirstResponder. Jeremy

I implemented a new feature that brings up an NSTextField for entering data. Once it's done, I call removeFromSuperview() and it goes away as expected. But then validateUserInterfaceItem is no longer

The document you cite is about Key Value Coding, not about Objective-C properties. The latter are not implemented using the former. If a @property declaration specifies a getter or setter method, the

Alex; I think you may be going down the wrong path on this one. It sounds more like a second instance is being created somehow. Did you guard the init method so that no one can create a second one,