Re: NSComboBox initialFirstResponder and nextKeyView Outlets
Re: NSComboBox initialFirstResponder and nextKeyView Outlets
- Subject: Re: NSComboBox initialFirstResponder and nextKeyView Outlets
- From: CHIMPO <email@hidden>
- Date: Thu, 14 Mar 2002 14:50:09 -0700
On Thu, 14 Mar 2002 00:57:09 -0700 you wrote:
>
I don't remember the specifics of the original thread... But it sounds
like> you don't want the value to be changed, but you do want the user to
still be> able to see what the available options were...
>
>
Forgive me if I'm running off on a tangent to nowheresville or
>
overcomplicating the obvious, but one of the major benefits behind a
>
ComboBox is that the user can tab to it and start typing to auto-select
a> value.
>
>
I'm left wondering why you would want the user to be able to tab to the
>
control if you don't want them to edit the value -- it seems
>
counter-intuitive. Granted I'm not "all users", but from my viewpoint
(from> a usability perspective) it makes sense that tabbing would/should
skip over> items that aren't currently editable anyway; otherwise the user
is left> wondering why they can access the field but not change it... not
to mention> the wasted keystroke.
>
I'm using the combo box as a list of items the user can choose from. For
instance, you have an application that displays a list of available
shipping options. You don't want a user to start entering in their own
shipping options because you wouldn't support whatever they put in. You
want to give the user a finite number of options to choose from and that's
it. They should be able to tab to the combo box because they want to
select one of the options.
>
You said you want the user to "use the tab key to tab through all of the
>
various input items in the gui and enter all of the information without
>
using a mouse". Well, if you don't want the item to be editable in the
>
first place, what information is there for the user to enter? If the
>
control is just plain not editable at all by anyone, then I'd wonder why
>
it's even on the interface...
Just because it's not editable doesn't mean a user can't interact with it.
>
I'm new to Cocoa and fairly new to programming in general, so I'm by no
>
means an expert... However, a possible workaround (assuming that users
>
would, at some point, be able to edit the value of the control) might be
to> use NSPopUpButton, which does what you're describing (almost) off the
shelf.
I'm new to Cocoa, but not programming. I'll look at the NSPopUpButton and
see if that fulfills my needs. I've done extensive windows gui
programming, and combo boxes are what I've always used in this type of
situation under MFC, so I figured they would work the same under a Mac
platform. That might not necessarily be a valid assumption. I bought the
Hillegass book last night and will work through it. This will hopefully
give me some more examples to work off of. I found the documentation to
be lacking in anything more than extremely basic example code.
>
You would need to do some validation of the menu items so that the
current> value (that you don't want the user to change -- yet) is the only
selectable> one. That way when they tab to it and it has focus, then can
use the down> arrow or the spacebar to see the other options, but the
validation you> implement would dim those options, preventing the user
from selecting them.>
>
From what I've read in the docs and on this list, that might be a
possible> route to explore if no one else chimes in with a more elegant
(and probably> simpler) solution...
>
>
Just my 2 cents (feel free to make change...)
>
>
Stephen
Thanks for the feedback.
Scott
_______________________________________________
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.