Hi Keary,
Thanks. I can confirm that this isn't having any effect in this case.
For now, a simple subclass of NSObjectController that recovers the
documented behaviour seems to be working satisfactorily for me.
There remains every chance that the documented behaviour I quoted
isn't the wh
On Mar 8, 2009, at 2:20 PM, Luke Evans wrote:
IIRC, NSObjectController, as a super class has some behavior that
doesn't make sense to an NSObjectControlelr proper. Because of this
it is possible that the selection change has been deferred to the
run loop. You can manually run the run loop
On 8-Mar-09, at 8:38 AM, Keary Suska wrote:
IIRC, NSObjectController, as a super class has some behavior that
doesn't make sense to an NSObjectControlelr proper. Because of this
it is possible that the selection change has been deferred to the
run loop. You can manually run the run loop to
On Sat, 7 Mar 2009 22:05:24 -0800, Luke Evans said:
>I'm a little bamboozled by a discovery I've just presently made.
>
>I was intending using an NSObjectController in one of my classes to
>keep a track of which visible object is selected. There are reasons
>why I've chosen to have an object cont
On Mar 7, 2009, at 11:05 PM, Luke Evans wrote:
Well, what actually happens is that -selectedObjects almost always
returns an empty array. Sending -setContent: does not appear to
result in this content being available as the selectedObject in the
way described (or there's other magic to ge
I'm a little bamboozled by a discovery I've just presently made.
I was intending using an NSObjectController in one of my classes to
keep a track of which visible object is selected. There are reasons
why I've chosen to have an object controller rather than just a
"selectedObject" ivar, wh
