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 21:01:50 +0100
Then I think we can cut this whole problem short if you simply put
all your views into an NSTabView and hook them up in IB that way. You
can hide the tabs on an NSTabView.
Yes, that was going to be the next stab. I wanted to exhaust the NSView
in NSView idea, which I guess I have.
If the delegate instance variable is declared as an IBOutlet, you
can. Or, if your view I subclassed from NSControl, it will also notice
the delegate outlet. I have the creeping fear that whatever "custom
view" this is, you're doing something very wrong. What kind of custom
view is this? You said they were text fields at first.
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.
What "ivar for the views"? What type is it? What object is it in?
It's in the controller and is declared as IBOutlet NSView *.
I think you don't quite understand what a delegate is. A delegate is
simply an object that will receive certain messages from the view, and
is thus able to customize that view's behavior. Delegates are solely
for you, the programmer. Superviews or other objects don't mess with
that.
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.
As I said before, when I had a NSView object, say NSBox, with a bunch
of NSTextFields in it, attached directly to the main window, there were
no problems with sending delegate messages back to my controller.
Everything worked fine. The problem started when I decided to
dynamically load one of three NSView, which now contained the
NSTextFields. Delegation messages stopped. It didn't make a lot of
sense, as I couldn't see, when adding a view via addSubview or
replaceSubview:, why the delegation messaging would be compromised.
What difference was it, if I placed the view directly on the main
windown in IB or loaded into the view programmatically?
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.
Yeah, that's fine. It worked fine when a single view was hooked into
the window. It's just now that one of three views is loaded
dynamically that the method isn't called -- whether by tabbing or
entering..
That's because you didn't tell the view who is its delegate. You need
to do that explicitly.
How do I tell a NSView object who it's delegate is when it doesn't
accept the setDelegate message?
I've set up the browser as firstResponder for the Window, and the
main window NSView as the nextKeyView (right or wrong?).
"Main window NSView"? I think you're doing too much. Leave
initialFirstResponder and nextKeyView alone.
Ok, I'll knock out all those connections.
Essentially, I could tab from my browser into the firstResponding
textField in the view, before implementing this dynamic loading of
different views.
Have you read the Hillegass book yet? It describes very clearly what
the initial first responder and nextKeyView are for. You might want to
try re-reading those parts.
I am in the middle of that, after the Learning Cocoa and Learning Cocoa
with ObjC, and hours of Apple documentation. Will continue to learn and
will try reorienting everything such that instead of loading three
different views, I'm showing/hiding tabs. Still don't understand why
the dynamic view loading doesn't work, but maybe as I learn more it'll
make sense.
J
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
~j~
James Tichenor
VFX Supervisor
AIM: email@hidden
(07779) 256 103
http://www.lehopictures.com/the_joint/
_______________________________________________
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