State based on front most document (was RE: Documentation frustrations)
State based on front most document (was RE: Documentation frustrations)
- Subject: State based on front most document (was RE: Documentation frustrations)
- From: Erik Buck <email@hidden>
- Date: Sun, 10 Jul 2005 22:27:22 -0400
Use the responder chain.
The responder chain is a critical design pattern in Cocoa and one of
the great strengths of Cocoa. Automatic menu validation (and much
more) works based on the responder chain. Maintaining the state of a
tool bar can/should also work based on the responder chain.
One implementation is to override -update in the subclass of NSPanel
that contains the tool bar or use the NSWindowDidUpdateNotification.
"- (void)update
Updates the window. The default implementation of this method does
nothing more than post an NSWindowDidUpdateNotification to the
default notification center. A subclass can override this method to
perform specialized operations, but should send an update message to
super just before returning. For example, the NSMenu class implements
this method to disable and enable menu commands.
An NSWindow is automatically sent an update message on every pass
through the event loop and before it’s displayed onscreen. You can
manually cause an update message to be sent to all visible NSWindows
through NSApplication’s updateWindows method.
See Also: – setWindowsNeedUpdate: (NSApplication), – updateWindows
(NSApplication) http://developer.apple.com/documentation/Cocoa/
Conceptual/WinPanel/Concepts/HowWindowIsDisplayed.html"
Inside your update method or NSWindowDidUpdateNotification handler,
for each control on the tool bar, use [NSApp targetForAction:
[currentControl action] to:[currentControl target]
from:currentControl]. If the value returned is nil, disable the
control. If the value is non-nil, further interrogate the returned
object to manage the state of the toolbar control.
"- (id)targetForAction:(SEL)anAction to:(id)aTarget from:(id)sender
Finds an object that can receive the message specified by the
selector anAction. If anAction is NULL, nil is returned. If aTarget
is nil, NSApp looks for an object that can respond to the message—
that is, an object that implements a method matching anAction. If
aTarget is not nil, aTarget is returned. The search begins with the
first responder of the key window. If the first responder does not
handle the message, it tries the first responder’s next responder and
continues following next responder links up the responder chain. If
none of the objects in the key window’s responder chain can handle
the message, NSApp asks the key window’s delegate whether it can
handle the message.
If the delegate cannot handle the message and the main window is
different from the key window, NSApp begins searching again with the
first responder in the main window. If objects in the main window
cannot handle the message, NSApp tries the main window’s delegate. If
it cannot handle the message, NSApp asks itself. If NSApp doesn’t
handle the message, it asks the application delegate. If there is no
object capable of handling the message, nil is returned.
See Also: – sendAction:to:from:, – tryToPerform:with:, –
targetForAction:"
In my extensive experience using Cocoa, if something that should be
easy seems hard or requires lots of steps, you are not taking
advantage of the frameworks. You should start by thinking, "lots of
applications manage tool bar state so there must be a convention or
framework supported way of doing that."
_______________________________________________
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