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 see if this is the
case.
It seems to me that there is no need for you to use -selectedObjects
when there will always be a 1:1 relationship between the controller
content and the selected object.
Yes, naturally if I change my selection code to just look at the
content then indeed everything works fine. However, see below...
I'm not sure about the run loop thing. Although I haven't tried this
in my test app yet, the behaviour in the main app seems to suggest
that changing the content object never updates the selectedObjects
array, except perhaps for the very first time.
On 8-Mar-09, at 10:55 AM, Matt Neuburg wrote:
Actually I think those reasons might be quite important here. I
could be
wrong, but on the face of it, it sounds like what you're describing
is a
total misuse of NSObjectController. So you might need to explain why
that
isn't the case. Or, putting it more broadly, it might be helpful if
you
described what are these objects, what is meant by selection, and
what is it
you're *really* trying to accomplish. m.
OK, fair enough. I have a range of controllers (mostly
NSArrayController, but others too) that are managing the presence,
ordering, selection of objects visible in various views across the
app. I'm now attempting to write a selection controller, "one ring to
rule them all", that will ensure that there's only one selected object
in the whole app - as a step toward an application inspector. I would
like all selection in the application therefore to be managed by a
NSObjectController or a subclass, so that I can rely on KVO and a
common API to obtain selected objects. I had one view that was doing
its own drawing of a data structure that didn't have such a controller
and was therefore looking for the simplest controller that could
become the local concept of selection there, and would be compatible
with the uber selection controller.
Reading the docs, NSObjectController seemed to fit the bill here.
It's the simplest of the concrete controllers, and the bit in the docs
about it presenting its lone content object as its selection was a
good fit. I therefore made an NSObjectCotnroller and had the
selection gestures do -setContent:, and the drawing code use -
selectedObjects to determine which of the drawn objects was selected,
for highlighting.
Anyway, I'm not exactly at an impasse. I can think of a variety of
approaches to having achieving what I want, but as usual when these
things arise, I'm curious whether I'm ignorant (have missed reading
some docs, unacquainted with some Cocoa 'lore'), if I'm barking
completely up the wrong tree, or if there's a genuine oddity/defect in
Cocoa's behaviour.
Failing anything better, I think my next step will be to subclass
NSObjectController to achieve the behaviour I'm expecting. I could
also use NSArrayController, and actually have it connected to the data
that is already driving the drawing of this view (without a controller
currently), but that seems a bit heavyweight when all I want to do is
have something track a single selected object references and present
the same selectedObjects interface as all the other controllers.
Thanks for the replies so far!
-- lwe
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
