Re: Where's the list box?
Re: Where's the list box?
- Subject: Re: Where's the list box?
- From: Robert Brown <email@hidden>
- Date: Fri, 11 Mar 2005 12:44:01 -0700
I'm thinking more along the lines of code when I talk about overkill. For both NSTableView and NSBrowser you have to implement a delegate to store the data. I'm thinking of a ListBox that works much like the combo box: you give it some items and it keeps track of them. I agree that NSTableView and NSBrowser work fine for this, but you do have to implement that extra class to take care of managing the data. For the case of a simple list of strings it would be nice to have a simple class that includes this functionality. It is definitely handy to have the ability to use a delegate to handle your data for more complex cases though.
On 11-Mar-05, at 11:41 AM, daniel wrote:
On Mar 11, 2005, at 10:10 AM, Robert Brown wrote:
Thanks for all the replies... I've looked at both the NSBrowser and NSTableView. Both seem to be a bit of overkill for my application.
Don't be afraid of using objects that are "too fancy for the purpose at hand." I think this is another flavor of the "instinct to optimize before necessary" problem. We use "overkill" objects every day. Your computer is wasting cycles as you read this.
In this case what are the particular fears of overkill? Since the code is already in memory - part of a standard framework that you are linking against, there is no code-bloating effect. The only memory overkill would be if the instances bring with them a needless amount of data. How much could there be? Imagine the unlikely scenario that as much as 1K of extra instance variables (that's a lot of empty instance variables, dictionaries, etc) that your imagined "NSScrollingList" wouldn't require. You'd still have to instantiate and use (and not release) 1000 scrolling lists before you wasted even 1MB of memory.
Performance overkill? Since the table view class is fairly adept at quickly displaying and handling several columns at once, it's almost certain to be fast enough for your 1-column case.
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_10_section_6.html#//apple_ref/doc/uid/TP30000359/TPXREF114
mentions a "scrolling list." That's the sort of thing I want... exactly like their example. I can see how both an NSTableView and NSBrowser could do this, but does a simple NSScrollingList or something exist?
Yeah, that document is somewhat framework independent. It describes it as "scrolling list" probably to avoid having to use either a Carbon or a Cocoa specific term.
The downside of not having an "NSScrollingList" class is that it's not obvious for newcomers what the best way to achieve the goal is. The upside is that once you've learned how to implement a scrolling list, you've also learned how to implement a scrolling multi-column list. It also makes it exceedingly easy to adapt when the marketing team informs you that in fact, you will need two display two columns of information in that list...
Daniel
---------------------------------------------------
Robb Brown
Seaman Family MR Research Centre
Calgary, Alberta, Canada
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden