Re: Simple NSWindowController (or window in secondary nib)
Re: Simple NSWindowController (or window in secondary nib)
- Subject: Re: Simple NSWindowController (or window in secondary nib)
- From: Graham Cox <email@hidden>
- Date: Sun, 7 Feb 2010 17:14:25 +1100
On 07/02/2010, at 5:05 PM, Trygve Inda wrote:
> I think a sheet would work just as well... In either case the columns will
> not adjust until the use clicks OK.
>
> My thought was to bind the checkboxes to BOOLs in a MutableDict within the
> TableController. Once the sheet is dismissed, I would just have the
> TableController read the state of the BOOLs and show/hide columns as needed.
>
> This MutableDict would later be saved to disk in the pref file so it'd be
> remembered at each launch.
>
> I would just need to operate on a copy of the real BOOLs (so Cancel would
> work), and have actions in the TableController for OK/Cancel.
>
> So maybe I don't need a separate controller and can just call
>
> [NSApp beginSheet:checkSheet modalForWindow:mainWindow modalDelegate:self
> didEndSelector:@selector(checkSheetDidEnd:returnCode:contextInfo:)
> contextInfo:nil];
>
> Thoughts?
It sounds reasonable I think.
In order to bind controls in the sheet to properties of the tableController, it will be definitely far easier to have everything in the one nib. You should still probably subclass NSWindowController for the sheet though, otherwise you'll be overloading the table controller to handle the OK/Cancel buttons of the sheet which really, are not logically its responsibility (neither are the checkboxes but using bindings blurs the otherwise clear lines of responsibility in this case).
Perhaps though instead of cancel/OK just allow the checkboxes to operate 'live' and have a 'Done' button. Modern interfaces tend to take this approach I think, though if it's unclear what's happening the more classic approach might be better.
I would also pass something in contextInfo so that the callback could be reused or else doesn't inadvertently get reused.
--Graham
_______________________________________________
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