Well, some further testing revealed that this was a way to make it work. It had the side benefit of making the window update more efficiently! Still, it would be nice to know why it was crashing in

Further experimentation reveals that the problem is (as far as I can tell) due to the code that handles a click updating the window. I seem to get a race condition: if I click, hold and drag, the drag

In a similar recent scenario, I found it takes two clicks when the text field is selectable but not editable. (Well, one click and one drag, if you’re actually trying to select text.) What makes

Wild guess, but what about the “can” methods. In the headers is there any hidden secret docs hat might help?

I’ve got a view-based NSTableView that uses NSTextFields. I’d like to be able to select text in some of the columns, mostly so it can be copied to the pasteboard. If I set the “selectable”

Gary L. Wade wrote on 27/4/19 02:07: Doesn't seem to help. Yes, it's a result of various ways of setting the range correctly. I've fixed it so it looks nicer. Yes, the range is correct after calling

The bug in documentation has been reported. Try forcing layout on the text view after setting the selection; there might be some kind of delay from setting it till it’s renderable, and that might

I don't have any useful help for you, but a couple of things struck me as odd about this. First of all, you're treating textView as an optional sometimes, and force-unwrapping it elsewhere. Prefacing

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