Re: self Changes on Open Panel
Re: self Changes on Open Panel
- Subject: Re: self Changes on Open Panel
- From: Quincey Morris <email@hidden>
- Date: Tue, 9 Jun 2009 17:31:45 -0700
On Jun 9, 2009, at 15:50, K. Darcy Otto wrote:
Bizarreness at **! I mean, -init is only run once!
Your first and *only* concern at this point is to work out why you
have 2 document objects. As a preliminary to that, you need to stop
thinking of the extra document object as a magical manifestation, and
realize that it's a consequence of either code you've written or a nib
file you've created.
Most likely, as I think someone already pointed out, you are getting
one document programatically, and have a spurious NSDocument object in
one of your nib files. In the former case, 'init' is called; in the
latter case, 'init' is *not* called, because the object is being
unarchived from the nib file -- you can expect that 'initWithCoder' is
called instead.
If you set a breakpoint in (say) 'windowControllerDidLoadNib', you
should land there twice, and be able to get a hint from the stack
backtrace as to where/why each document is being created. Keep in
mind, though, that I don't think you've necessarily established that
the magical manifestation document is of class 'MyDocument', so it may
land at [NSDocument windowControllerDidLoadNib] instead of [MyDocument
windowControllerDidLoadNib].
On Jun 9, 2009, at 15:55, K. Darcy Otto wrote:
The reason I want to know whether the panel is open, is that I want
to disable certain menu options via -validateUserInterfaceItem while
that panel is open. The panel is a sheet that comes down in front
of the document window when the document window is first opened (a
la Pages or Keynote when they show you templates), and as long as it
is down, I don't want users to be able to access the "delete line"
menu option.
This doesn't sound like the right approach. When the sheet is
displayed, 'validateUserInterfaceItem' proceeds up the responder
chain, which doesn't include the underlying window at that point.
Unless your sheet's 'validateUserInterfaceItem' (if there is one)
enables Delete Line, it should be disabled.
The fact that (I presume) you're seeing it enabled suggests that the
menu item's target is connected directly to the underlying window,
window controller or document. Doing that bypasses the responder chain
mechanism. You'd do better to connect the target to "First Responder"
in the menu nib file. That'll have the effect of automatically
disabling the menu item when the sheet (or any sheet) is up.
I can think of pathological cases where the underlying
'validateUserInterfaceItem' might need to know if a particular sheet
is displayed, but it doesn't really sound like that's what is
necessary here.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden