Re: [NEWBIE]: Dynamically loading NSViews
Re: [NEWBIE]: Dynamically loading NSViews
- Subject: Re: [NEWBIE]: Dynamically loading NSViews
- From: J Tichenor <email@hidden>
- Date: Sat, 2 Oct 2004 22:15:04 +0100
At 21:01 Uhr +0100 02.10.2004, J Tichenor wrote:
The custom views are just that - the custom view from the IB palette,
with an IBOutlet NSView ivar pointing to each one from the
controller.
Ah, okay. That's what I would call an NSView as a top-level object in
the NIB. So, is this NSView empty, or are there other views inside it?
A plain and simple NSView is just a container for other views. It
can't have the keyboard focus itself, nor a delegate.
What you'd want to do would be to put your views into this NSView,
and hook up the outlets of those views to your other objects. E.g. if
you have an NSTextField in your NSView, that NSTextField will have a
delegate outlet that you can connect. *not* the NSView around it. For
the same reason, if you hook up initialFirstResponder or nextKeyView,
you don't connect that to an NSView, but rather to a view that can
actually have focus, like your NSTextField. Is that your problem, or
did you try that?
Yes, I just posted a wrapup message as yours came in. That was my error
-- somehow assuming that the underlying NSView dictated delegation
rather than each NSTextField, etc... Once I hooked those up to the
controller/delegate everything started to work fine. Also took your
suggestion of going with a hidden tabView, although as I said, I
suspect that my idea of loading NSViews dynamically would probably work
fine, now that I realized my error.
Still learning as I go, for sure. My understanding of the delegate is
as an object to receive messages as determined by the sending object.
Well, that's not all. That's simply a target of a message. If the
object "B" is the delegate of the object "A", then "A" must have a
"delegate" outlet that is connected to "B". Depending on how much
control "A" offers to its delegates, "A" will send notifications to
"B", or it will even call methods on "B" that return a value or are
expected to perform a particular action.
E.g. the delegate "B" can make decisions on behalf of "A" (like "can
this list item be selected?") or it can perform actions, like
accepting objects being dragged onto "A". (that's the case of
NSTableView)
Good. I'm in the right ballpark, just not being specific enough.
Are you perhaps mixing up the responder chain and delegates? That's
two entirely different things.
I might well be. I figured delegation runs the same path that the
responder chain does, but I guess I've got that mixed up.
The nextKeyView doesn't really have much to do with the responder
either. All it does is set up the tabbing order in a window. It starts
with the initialFirstResponder, or the first text field in the window,
and when you hit the tab key it progresses to the next text field in
the window. I.e. this is just for letting people not use the mouse
when working with lots of text fields.
I'm still trying to get my tabbing working again. Once the user has
found the record they want to work on in the browser, they should be
able to hit tab which will take them to the first field of the relevant
tabView. For whatever reason, that doesn't work.
Finally, there's notifications, which are again different, and are a
one-to-many matter. One object sends a notification, and anyone
interested can register to receive this notification. E.g. there's a
notification that lets you detect when the computer goes to sleep or
wakes up again, when a CD has been inserted etc.
Yes, I'm working my way through Notifications too :-)
How do I tell a NSView object who it's delegate is when it doesn't
accept the setDelegate message?
An NSView doesn't have a delegate. It wouldn't make sense. All an
instance of NSView does is display other views embedded in it, and
forward clicks to them. If you have nothing to do, you have nothing to
delegate. Select your NSTextField or whatever is inside that NSView.
It will have a "delegate" outlet.
Yes, that was exactly where my problem lay, as mentioned. Thank you
very much for working through this me!
J
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden