Re: Bind View-Based NSTableView to array of dictionaries in user defaults

> On 2016 May 06, at 07:58, Keary Suska wrote: > If you substitute with a cell-based table, it works flawlessly. > I was able to get it to work properly by proxy-ing the array in the app > delegate Keary, thank you very much for taking the time to test my demo

Re: Very basic need, very difficult to achieve.

> On May 6, 2016, at 11:19 AM, Richard Charles wrote: > > >> On May 5, 2016, at 10:33 PM, Charles Srstka wrote: >> >>> On May 5, 2016, at 9:39 PM, Richard Charles wrote: >>> >>> On May 5, 2016, at 6:07 PM, Richard

Re: Very basic need, very difficult to achieve.

I can't say that this is complete or there won't be any gotchas for specific use cases, but here's what I can think of. 1. Preserving access in the App Store If you don't "Purchase" the OS installer before the next release you won't be able to download a new copy in the future.

Re: Receiver type for instance message is a forward declaration

On May 6, 2016, at 14:58 , Alex Zavatone wrote: > > Can we come up with a suitable set of tests to replicate and verify this This was the code from the forum thread that I played around with: > class ViewController: UIViewController { > let backgroundQueue =

Re: Receiver type for instance message is a forward declaration

> On May 6, 2016, at 2:34 PM, Quincey Morris > wrote: > > On May 6, 2016, at 13:32 , Carl Hoefs > wrote: >> >> Once in a while, NSOperationQueue -addOperation: throws an exception. I

Re: Receiver type for instance message is a forward declaration

Can we come up with a suitable set of tests to replicate and verify this, like a bunch of dispatch_async calls to increment an NSInteger and then to decrement the NSInteger that repeats while true? Sent from my iPhone > On May 6, 2016, at 5:34 PM, Quincey Morris >

Re: Receiver type for instance message is a forward declaration

On May 6, 2016, at 13:32 , Carl Hoefs wrote: > > Once in a while, NSOperationQueue -addOperation: throws an exception. I guess > this is a well-known bug going all the way back to 2008. I found Mike Ash's > writeup on the issue, and have downloaded his

Re: Receiver type for instance message is a forward declaration

> On May 6, 2016, at 1:42 PM, Carl Hoefs wrote: > > I would have thought that this earlier line would have been flagged if > RAOperation.h hadn't been included: > > RAOperation *op = [self _popOperation: listPtr]; There must be a forward declaration

Re: Receiver type for instance message is a forward declaration

> On May 6, 2016, at 1:35 PM, John McCall wrote: > >> On May 6, 2016, at 1:32 PM, Carl Hoefs >> wrote: >> I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in >> a while, NSOperationQueue -addOperation: throws an

Re: Receiver type for instance message is a forward declaration

> On May 6, 2016, at 1:32 PM, Carl Hoefs wrote: > I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a > while, NSOperationQueue -addOperation: throws an exception. I guess this is a > well-known bug going all the way back to 2008. I

Receiver type for instance message is a forward declaration

I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a while, NSOperationQueue -addOperation: throws an exception. I guess this is a well-known bug going all the way back to 2008. I found Mike Ash's writeup on the issue, and have downloaded his replacement class,

Re: NSTableView is messaging zombie delegate

> On May 6, 2016, at 1:03 PM, Matthew LeRoy wrote: > > My understanding is that NSTableView's delegate is a zeroing weak reference Are you sure? Historically it’s been unsafe_unretained — in the old days before weak references or ARC, the view never retained nor released

Re: NSTableView is messaging zombie delegate

> On 6 May 2016, at 21:03, Matthew LeRoy wrote: > > Hello, > > I'm having an issue where an NSTableView appears to be messaging its delegate > after the delegate has been deallocated, causing an EXC_BAD_ACCESS crash. It > doesn't always happen, but it happens regularly.

NSTableView is messaging zombie delegate

Hello, I'm having an issue where an NSTableView appears to be messaging its delegate after the delegate has been deallocated, causing an EXC_BAD_ACCESS crash. It doesn't always happen, but it happens regularly. My understanding is that NSTableView's delegate is a zeroing weak reference, and so

Re: Very basic need, very difficult to achieve.

> On May 5, 2016, at 10:33 PM, Charles Srstka wrote: > >> On May 5, 2016, at 9:39 PM, Richard Charles wrote: >> >> >>> On May 5, 2016, at 6:07 PM, Richard Charles wrote: >>> >>> Can you run this application? >>> >>>

Re: Bind NSTableView to array of dictionaries in user defaults

> On May 5, 2016, at 7:47 PM, Jerry Krinock wrote: > > After reading Quincey’s reply, I had concluded that this is one of those > cases where Cocoa Bindings requires additional “glue”, which defeats one of > the two purposes of Cocoa Bindings. But it would be very cool if

Re: Can't make an adaptive segue push

> On 6 May 2016, at 20:49, Roland King wrote: > > I have a navigation controller as the detail pane of a UISplitView (pretty > much right from the standard splitview template). > > Now I want to push another view onto that stack. I have the view, I’ve > dragged out a segue to

Can't make an adaptive segue push

I have a navigation controller as the detail pane of a UISplitView (pretty much right from the standard splitview template). Now I want to push another view onto that stack. I have the view, I’ve dragged out a segue to connect it up however none of the available ‘adaptive segues’ do a ‘push’.