> Message: 1
> Date: Sun, 20 Apr 2008 14:02:52 -0600
> From: Keary Suska <[EMAIL PROTECTED]>
> Subject: Re: Binding NSButton enabled state
> To: "Cocoa-Dev (Apple)" <cocoa-dev@lists.apple.com>
> Message-ID: <[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> >
> Content-Type: text/plain; charset="US-ASCII"
>
> on 4/20/08 11:47 AM, [EMAIL PROTECTED] purportedly said:
>
> > On Sat, Apr 19, 2008 at 11:55 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> >
> >> On Apr 19, 2008, at 11:08 AM, Lorenzo Thurman wrote:
> >>
> >> I have two NSTableViews, tableA and tableB, each managed by separate
> >>> NSArrayControllers. When a selection is made in either table, an
> >>> instance
> >>> variable is set. I want to have an NSButton's enabled state to 'YES'
> >>> whenever the instance variable is set.
> >>>
> >>
> >> Don't think of it as an instance variable, think of it as a property.
> >> Restating your problem, you want your "Do Something" button's enabled
> >> property to be bound to your window controller's "can do something"
> >> property.
> >>
> >> What this means is that you need to manipulate your window controller's
> >> "can do something" property in a way that things bound to it can notice
> --
> >> in other words, in a way that will post key-value observing
> notifications.
> >> Thus instead of manipulating it as an instance variable, you should
> just
> >> always invoke its setter.
> >>
> >> You haven't said how you're actually noticing that the selection in one
> of
> >> your tables has changed; I assume you're either using an NSTableView
> >> delegate method or a notification to do so.
> >>
> >> -- Chris
> >>
> >>
> > Here's my code:I register to receive these notifications when the
> selection
> > changes.
> >
> > -(void)applicationDidFinishLaunching:(NSNotification*)not{
> >
> >
> > [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector(
> > usTableViewSelectionDidChange:) name:
> > NSTableViewSelectionDidChangeNotification object:usCityTable];
> >
> > [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector(
> > intlableViewSelectionDidChange:) name:
> > NSTableViewSelectionDidChangeNotification object:intlTable];
> >
> > }
> >
> >
> > These are the messages sent when a selection is changed (Is there a way
> to
> > use just one?):
>
> Yes, if instead you make your controlling object the delegate to both
> tableviews and implement -tableViewSelectionDidChange:.
>
> > -(void) usTableViewSelectionDidChange:(NSNotification*)not{
> >
> > NSArray* selObjs = [usTableContent selectedObjects];
> >
> > if([selObjs count] > 0) {
> >
> > [intlTable deselectAll:self];
> >
> > NSDictionary* selectedDictionary = [selObjs objectAtIndex:0];
> >
> > [self setValue:[selectedDictionary objectForKey:@"location"] forKey:
> > @"location"];
> >
> > [self setSelectedItem:selectedDictionary];
> >
> > }
> >
> > }
> >
> > -(void) intlableViewSelectionDidChange:(NSNotification*)not{
> >
> > NSArray* selObjs = [intlTableContent selectedObjects];
> >
> > if([selObjs count] > 0){
> >
> > [cityTable deselectAll:self];
> >
> > NSDictionary* selectedDictionary = [selObjs objectAtIndex:0];
> >
> > [self setValue:[selectedDictionary objectForKey:@"location"] forKey:
> > @"location"];
> >
> > [self setSelectedItem:selectedDictionary];
> >
> > }
> >
> >
> > }
>
> Note that when you call -deselectAll:, that triggers an
> NSTableViewSelectionDidChangeNotification, so you may want to watch out.
> Your checks probably avoid loops, but the notifications will get sent more
> often than is necessary.
>
> Anyway, what kind of object is "location"? Are you applying any
> transformers? If not, how are you considering how your object will get
> coerced into a boolean?
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
>
>
> I'll look at the tableview deleegates again. I looked at those before, but
reasoned that they might not work as I would like, but I can't remember why.
Thanks for pointing out the potential for looping and the extra
notifications that get sent, but the problem I ran into without the
deselectAll, was that if I made a selection in tableA, my interface updated
correctly, then made a selection in tableB, my interface updated correctly,
but then made the same selection again in tableA as before, my interface did
not update correctly (since technically, there was no change in the
selection of tableA, so the notification is not sent). The selections in the
tables are mutually exclusive. That's an important point I neglected to add
to my original post. By the way, the "location" variable is an NSString. The
window cannot be dismissed using "Save" unless "location" actually has a
value, other than @"", of course. (there is a "Cancel" button). This is a
preferences window that cannot be dismissed using "Save" until "location" is
set or the cancel button is selected. Once it's set, the next time the user
opens the prefs, the "Save" button is enabled, since "location" takes its
value from user defaults, where its saved once set. So its really a first
run problem that I have here. This brings up another question, but that will
be another post shortly.
Thanks for the help.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
