First Responder

  • I have a menu item connected to an action in First Responder;

    The action exists in an NSView subclass.

    The subclass implements acceptsFirstResonder and return YES.

    The subclass implements validateMenuItem and return YES;

    When the menu displays the menu item is disabled (set to enabled in IB).

    Is this not the proper implementation?

    -koko
  • On Thu, May 10, 2012 at 6:24 PM, koko <koko...> wrote:
    > I have a menu item connected to an action in First Responder;
    >
    > The action exists in an NSView subclass.
    >
    > The subclass implements acceptsFirstResonder and return YES.
    >
    > The subclass implements validateMenuItem and return YES;
    >
    > When the menu displays the menu item is disabled (set to enabled in IB).
    >
    > Is this not the proper implementation?

    Does your subclass implement the action that the menu item is looking
    for? Your view subclass won't be chosen as the first responder if it
    doesn't implement the action.
  • I have had this happen when I have forgotten to declare my action method in the public header.

    Erik Stainsby
    <erik.stainsby...>
    -------------------------------------

    On 2012-05-10, at 4:24 PM, koko wrote:

    > I have a menu item connected to an action in First Responder;
    >
    > The action exists in an NSView subclass.
    >
    > The subclass implements acceptsFirstResonder and return YES.
    >
    > The subclass implements validateMenuItem and return YES;
    >
    > When the menu displays the menu item is disabled (set to enabled in IB).
    >
    > Is this not the proper implementation?
    >
    > -koko
  • On May 10, 2012, at 6:05 PM, Stephen J. Butler wrote:

    > Does your subclass implement the action that the menu item is looking
    > for? Your view subclass won't be chosen as the first responder if it
    > doesn't implement the action

    Yes, the subclass implements the action.
  • On May 10, 2012, at 6:05 PM, Erik Stainsby wrote:

    > I have had this happen when I have forgotten to declare my action method in the public header.

    The action is declared in the subclass header.
  • Could you please paste the a copy of the method in a message? It is far easier to help you debug code which we can see than a description of something we cannot see.

    Erik Stainsby
    <erik.stainsby...>
    -------------------------------------

    On 2012-05-10, at 5:07 PM, koko wrote:

    >
    > On May 10, 2012, at 6:05 PM, Erik Stainsby wrote:
    >
    >> I have had this happen when I have forgotten to declare my action method in the public header.
    >
    > The action is declared in the subclass header.
    >
    >
  • On 5/10/12 4:24 PM, koko wrote:
    > I have a menu item connected to an action in First Responder;
    >
    > The action exists in an NSView subclass.
    >
    > The subclass implements acceptsFirstResonder and return YES.
    >
    > The subclass implements validateMenuItem and return YES;
    >
    > When the menu displays the menu item is disabled (set to enabled in IB).
    >
    > Is this not the proper implementation?

    Let's cut to something more basic: is your view ACTUALLY in the
    responder chain?

    Since you apparently are expecting it to become firstResponder, do you
    actually make sure that it does (for example, by sending its window
    -makeFirstResponder: or marking it as the window's initialFirstResponder)?

    Remember that overriding acceptsFirstResponder does not magically put a
    view in the responder chain.  (In addition to -makeFirstResponder: the
    view could also of course acquire first responder status in the usual
    manner, by user interaction.)

    --
    Conrad Shultz

    Synthetiq Solutions
    www.synthetiqsolutions.com
  • koko wrote:

    > I have a menu item connected to an action in First Responder;
    >
    > The action exists in an NSView subclass.
    >
    > The subclass implements acceptsFirstResonder and return YES.
    >
    > The subclass implements validateMenuItem and return YES;
    >
    > When the menu displays the menu item is disabled (set to enabled in IB).
    >
    > Is this not the proper implementation?

    Absent from this narrative: Any indication that you have reason to believe your view has actually *become* the first responder.
  • On May 11, 2012, at 4:25 AM, Gregory Weston wrote:

    > Absent from this narrative: Any indication that you have reason to believe your view has actually *become* the first responder.

    The Window contains many views, each with a particular function to the application.

    Now, this may be y ignorance, but as I have understood ... NSViews are part of the responder chain and that the responder chain is traversed to find an action corresponding to the control or menu item connection.  That views must implement accepts first responder to be pat of this process.

    Now, if what is being said is that a view cannot participate in this process until the user clicks the view, well ok. But what good is the responder chain if all views that acceptFirstResponder are not part of it ?

    -koko
  • On 11 May 2012, at 8:56 AM, koko wrote:

    > Now, if what is being said is that a view cannot participate in this process until the user clicks the view, well ok. But what good is the responder chain if all views that acceptFirstResponder are not part of it ?

    Your understanding that only the focused view (among views) can be first responder is correct. This is reflected in "responder" being singular and not plural.

    Imagine a window with several NSTextFields. Imagine Edit > Select All being selected. This sends a selectAll: message to the first responder (and up the responder chain until a handler is found, or the chain is exhausted). Making every NSTextField the first responder would make the effect of the select-all indeterminate, which is undesirable.

    — F
  • On May 11, 2012, at 8:28 AM, Fritz Anderson wrote:

    > Your understanding that only the focused view (among views) can be first responder is correct. This is reflected in "responder" being singular and not plural.

    koko grok
  • On 11/05/2012, at 11:56 PM, koko wrote:

    > But what good is the responder chain if all views that acceptFirstResponder are not part of it ?

    Because the purpose of the responder chain is to provide a context for the keyboard and other shared inputs, like the menu bar. While the user can click in any view at any time, and the mouse location selects which view gets the message, the keyboard needs another way to select which object the message is sent to.

    --Graham
  • Thanks for the courtesy of an edifying reply  ...  koko now grok more better.

    On May 11, 2012, at 4:25 PM, Graham Cox wrote:

    >
    > On 11/05/2012, at 11:56 PM, koko wrote:
    >
    >> But what good is the responder chain if all views that acceptFirstResponder are not part of it ?
    >
    >
    > Because the purpose of the responder chain is to provide a context for the keyboard and other shared inputs, like the menu bar. While the user can click in any view at any time, and the mouse location selects which view gets the message, the keyboard needs another way to select which object the message is sent to.
    >
    > --Graham
  • On 11 במאי 2012, at 03:11, koko wrote:
    > I have a menu item connected to an action in First Responder;
    > The action exists in an NSView subclass.
    > The subclass implements acceptsFirstResonder and return YES.
    > The subclass implements validateMenuItem and return YES;
    > When the menu displays the menu item is disabled (set to enabled in IB).
    > Is this not the proper implementation?

    Hello.

    Your implementation is complete and you understood it right. But I'm afraid you missed the architectural level...

    An NSResponder (such as your view) is given a chance to respond only when it is in the responder chain, and no one down the responder chain responds earlier.

    Practically - just click on your view to select it/focus on it/make it the first-responder  then try again your menu item. You'll have a nice surprise.

    The whole responder-chain thing is about context and focus. Many objects can implement the same action, and depending on user focus, they will become the first to get a chance to handle the action.

    If you want the action to be handled even when the view is out-of-focus (not in focus, and not containing the currently focused element, not in the current responder chain) than you must move the action implementation (and menu-validation) to some other view or controller up the chain, that is always "there" - in the responder chain - when the user wishes to perform the action.

    For example you'd always want the "Save..." to be available, regardless of the current user focus on this view or another within the window. But you still want to have different "Save..." handlers act, for different windows. right?

    So you'll put your -(IBAction)save:(id)sender; implementation in your WindowController. It is high enough in the view hierarchy, and in the responder chain to be always available (when some window is active), but when user switched between windows --- he'll have different responder-chains that lead (up the chain) to different window controllers!

    I hope this explanation helps.

    Motti Shneor, Mac OS X Software Architect & Team Leader
    Spectrum Reflections Ltd.
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today