Re: Disabling items in NSTabView
Re: Disabling items in NSTabView
- Subject: Re: Disabling items in NSTabView
- From: "Daniel T. Staal" <email@hidden>
- Date: Tue, 29 May 2007 15:52:23 -0400 (EDT)
- Importance: Normal
On Tue, May 29, 2007 3:02 pm, I. Savant said:
> On 5/29/07, Daniel T. Staal <email@hidden> wrote:
>> 1: Manually disable every item that is placed on any tab in the
>> NSTabView.
>
> Barring the 4th option I'll mention below, I'd say this is the most
> common approach. Nothing wrong with it at all, really.
>
>> 2: Replace the NSTabView with a look-alike (maybe just an image) that
>> is disabled.
>
> Eeew.
Agreed. :)
>> 3: Say 'Fuck it' and just hide the whole thing unless the file is
>> unlocked.
>
> As an aside, let's keep the more vulgar cursing for another list. There
> are younger subscribers on this particular one. In response to the point
> itself, you could do this, but I'm a firm believer in showing the
> potential, despite the state, if you get my meaning.
I do, and that's why I hadn't done it. (And sorry about the language.
I'm used to computer lists being PG-13 or above.)
>> #1 would work, but is a lot of manual work and looks to be an
>> invitation to bug city. (All I have to do is forget one someplace...)
>
> Not really, no. Factor it out into a single method like
> "-setEditorControlsEnabled:".
Mainly bug city because I'm planing 5-6 tabs, each with 8-9 controls
minimum, and I'm still developing the interface, so my short memory span
is likely to have me forgetting one. I hate relying on my own memory to
make lists: That's what computers are for.
>> Can anyone here think of a better idea? Is there a good way to get a
>> list of all the controls on an NSTabView?
>
> Glad you asked. The 4th option: Bindings. Bind the enabled state of all
> your relevant controls to the "locked" state (with the NSNegateBoolean
> value transformer to flip the state).
Nice. Not actually less work than my option 1, but a bit 'cleaner'. (And
I don't have to create outlets for all of them if I don't need to...)
Thanks for the pointer.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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