Re: Non user-selectable NSMixedState
Re: Non user-selectable NSMixedState
- Subject: Re: Non user-selectable NSMixedState
- From: Phillip Ulrich <email@hidden>
- Date: Wed, 18 Sep 2002 01:55:19 -0400
Maybe just a shot in the dark, but why not offer a set of radio buttons
instead? One for "all invisible," one for "none invisible," and one
for "some invisible, some not." If you want to make all the files
invisible, use that button; if making them un-invisible, use that
button, and only bring the third button into play if they select a
group of files with a mixed invisibility state.
Just my 2 cents, for what it's worth.
--Phil
On Wednesday, September 18, 2002, at 01:11 AM, Clark Mueller wrote:
>
I haven't CCed the list on this one (bandwidth is expensive, and I'm
>
providing a download :-) ). Have a look at http://www.finikin.com/,
>
and download Modifier 2.5b4 (this is kind of dated, but you'll see
>
what I'm doing). It's in the batch window that I'm having this
>
particular problem... I used Ondra's solution for it, which was to
>
intercept the clicks on the check boxes, and simply force the next
>
next state if the next state was supposed to be mixed. HOWEVER, what
>
you just mentioned finally clicked, i.e., a change that can be
>
reversed. Because with this window, nothing is applied until the user
>
presses "Apply", having mixed state selectable is probably a very good
>
idea. My conflict is mainly that I don't know what to force it to if
>
they've selected it when ALL active files were originally one state or
>
the other. I can probably put in something to programatically catch
>
this one too, but I have to think about whether I want that to behave
>
that way or not.
>
>
Something else - what you were referring to with "running into this
>
problem myself shortly"? Do you mean the check box dilemma or the
>
invisibility/file attribute type stuff?
>
>
Thanks,
>
>
-c
>
email@hidden
>
>
On Tuesday, September 17, 2002, at 10:25 PM, Dustin Voss wrote:
>
>
> The UIs I've seen handle this sort of situation like so: the user
>
> check-marks the item, means "make all invisible", the user
>
> un-check-marks the item, means "make all visible", the user selects
>
> the mixed state again, means "oops, don't change anything". But I
>
> imagine that can be tricky to code, and I can see usability arguments
>
> on both sides. I'll be running into this problem myself shortly.
>
>
>
> On Tuesday, September 17, 2002, at 06:10 PM, Clark Mueller wrote:
>
>
>
>> Kind of a hassle to do that, but it's not hard, so I won't complain.
>
>> :-) It is as intuitive as it would be. What I am using them for is
>
>> to view the state of the visibility flag on multiple files. I use
>
>> NSOnState if they are all invisible, NSOffState if they are all
>
>> visible, and NSMixedState if some are, and some are not. The user
>
>> can then change the state of the files. I cannot change it to
>
>> half-on, half-of (i.e. NSMixedState), just all invisible, or all
>
>> visible. Does this make sense as an intuitive interface?
>
>>
>
>> Thanks,
>
>>
>
>> -c
>
>> email@hidden
>
>>
>
>> On Tuesday, September 17, 2002, at 06:47 PM, Ondra Cada wrote:
>
>>
>
>>> On Wednesday, September 18, 2002, at 02:31 , Clark Mueller wrote:
>
>>>
>
>>>> I have several check boxes. I need to configure them to be any of
>
>>>> the three states (on, off, mixed). However, I only want the user
>
>>>> to be able to select on and off. I am able to setAllowsMixedState
>
>>>> to YES, and then I can set them to what I need. However, if I then
>
>>>> change this back to NO so that the user can only select on or off,
>
>>>> then it strips any mixed state that I may have set. Is there a way
>
>>>> that I can have the user select from just the two, while
>
>>>> programatically still being allowed to set any state?
>
>>>
>
>>> Are you quite sure such a GUI is still reasonably intuitive?
>
>>>
>
>>> Anyroad; the only colution I see offhand would be to link those
>
>>> buttons to some action, which would check the state just selected
>
>>> and immediately change it if it is the "forbidden" one.
>
>> _______________________________________________
>
>> cocoa-dev mailing list | email@hidden
>
>> Help/Unsubscribe/Archives:
>
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
>> Do not post admin requests to the list. They will be ignored.
>
> _______________________________________________
>
> cocoa-dev mailing list | email@hidden
>
> Help/Unsubscribe/Archives:
>
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
> Do not post admin requests to the list. They will be ignored.
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.