• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Kludges when binding to 'value' of Menu Items
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kludges when binding to 'value' of Menu Items


  • Subject: Re: Kludges when binding to 'value' of Menu Items
  • From: Jerry Krinock <email@hidden>
  • Date: Tue, 16 Oct 2007 10:26:29 -0700


On 2007 Oct, 16, at 6:37, I. Savant wrote:

  You can always bind to File's Owner (NSApplication) with the keypath
of "mainWindow.windowController.document.myBooleanKey" ...

Wow. That would be really slick if it would work. To test this, first I purposely misspelled myBooleanKey and immediately got a "not key-value compliant" error, as expected. But after I spelled it correctly, I get weird errors when I try and switch or open a window, such as...


*** -[NSNull identifier]: selector not recognized [self = 0xa080b040]
*** Exception raised during posting of notification. Ignored. exception: *** -[NSNull identifier]: selector not recognized [self = 0xa080b040]
*** [<SSDocChildWindow 0x15fb9700> removeObserver:<NSKeyValueObservationForwarder 0x3b3800> forKeyPath:@"windowController.document.browfile.displayHierarchy"] was sent to an object that has no observers.


(Note: SSDocChildWindow is the subclass of NSWindow I use for my document windows, and myBooleanKey is 'displayHierarchy'.)

I don't get any of those errors if I simply un-check that binding in Interface Builder. It looks like it gets confused when it needs to start observing a different browfile due to a mainWindow change, thinking that it was observing the window at the beginning of the keyPath, instead of the 'browfile' at the end of the keyPath.

Have you, I.S., or anyone ever seen such a clever binding through NSApp work? (If it was in a sample project somewhere that would be great!)

Issue #2...

Besides the above problem, there's also the issue that menu items
need a dummy "target" to ever be enabled, even if their action is
accomplished via bindings.  So I wire all their targets to this...

I'm not sure if I fully understand you, but you can connect the menu item to First Responder ... that will give you *a* target and depending on your app, it could be the frontmost document (or a text view selected therein).

I should have emphasized the 'action' within the target. Sure, I can target First Responder (or AppController), but in either case I need to connect to and define an action within that target, and this action needs to do nothing, except smile pretty when the menu item is validated. So I use 'dummyAction:(id)sender{}', and I was wondering if anyone knows a better way, since this looks like a kludge.
_______________________________________________


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


  • Follow-Ups:
    • Re: Kludges when binding to 'value' of Menu Items
      • From: "I. Savant" <email@hidden>
References: 
 >Kludges when binding to 'value' of Menu Items (From: Jerry Krinock <email@hidden>)
 >Re: Kludges when binding to 'value' of Menu Items (From: "I. Savant" <email@hidden>)

  • Prev by Date: Re: warning: assignment makes integer from pointer without a cast
  • Next by Date: Re: Question about laterDate: and earlierDate:
  • Previous by thread: Re: Kludges when binding to 'value' of Menu Items
  • Next by thread: Re: Kludges when binding to 'value' of Menu Items
  • Index(es):
    • Date
    • Thread