Re: Newbie Question: NSTableView.DataSource
Re: Newbie Question: NSTableView.DataSource
- Subject: Re: Newbie Question: NSTableView.DataSource
- From: Tyler LaGrange <email@hidden>
- Date: Fri, 11 May 2001 16:09:57 -0400
On Friday, May 11, 2001, at 11:40 AM, mmalcolm crawford wrote:
>
Tyler LaGrange wrote:
>
>
This is misleading in a couple of significant ways:
Hey. I said this example worked! Not worked correctly. I should have
titled it to be a Newbie Answer. Thanks for the help though........
>
>
> public abstract class groupNSTableData implements
>
> NSTableView.DataSource
>
>
>
There is no need to implement the NSTableView.DataSource interface.
>
Objects with delegates use introspection to discover what methods the
>
delegate implements, and only call those.
I will have to try that out then. I was a little confused by the fact
that the Cocoa Java API called it an abstract class and all. Most of
the other stuff I have seen about abstract classes used the implements
stuff. Not to mention the ProjectBuilder error messages didn't really
help too much. But once I did all this it compiled and ran! I think I
am understanding what the delegates do, but it will probably take a
little time. Is there anything in the documentation or anywhere that
will help explain these "delegates"?
>
>
> private HashMap groupMap = new HashMap();
>
>
I'm not sure why you're using a HashMap rather then, say, a Vector, or
>
better still an NSMutableArray? The goal of a table view is to display
>
an ordered collection of elements. Putting the elements into a hash
>
table with string keys "1", "2", "3", etc. seems "unusual". I suspect
>
you'll run into interesting problems if you try to remove elements...
um. oops. calling this "unusual" was a very nice way for you to point
out how wrong this is. It worked for what I was doing! - but I wasn't
trying to remove objects. I don't know why I used a HashMap. I can
tell you the reason I didn't use the NSMutableArray is because I don't
know what it is yet. I haven't started in to the foundation classes
just yet. Just playing with the appKit for now...
>
>
> public void addGroup(String _name)
>
> {
>
> groupMap.put(Integer.toString(groupMap.size()),_name);
>
> }
>
>
>
You may want to inform the table view that its contents have changed:
>
>
tableView.reloadData();
>
tableView.selectRow(row, false);
>
tableView.scrollRowToVisible(row);
>
>
or possibly just:
>
tableView.noteNumberOfRowsChanged();
definitely good suggestions....
>
>
> public Object tableViewObjectValueForLocation(NSTableView tv,
>
> NSTableColumn tc, int i)
>
> {
>
> return groupMap.get(Integer.toString(i));
>
> }
>
>
>
This is fine for a table displaying one column, but it won't scale to
>
multiple columns.
>
The way that this works "best" is if your elements inherit from
>
NSObject, so you can take advantage of key-value coding:
>
>
String identifier = (String)tc.identifier();
>
NSObject nso = (NSObject)aNSMutableArray().objectAtIndex(row);
>
return nso.valueForKey(identifier);
I wish you had tried to help this guy out before I did! It just didn't
look like anybody was helping him and since I had a little luck getting
some data to show up I figured I would let him know. Maybe I'll put
something else together with your suggestions that isn't coded as bad as
this first attempt at understanding the NSTableView and we can try this
again.
>
>
> AND - then in your Controller class you would have this:
>
>
It is often the case that the Controller and data source are the same
>
object.
The other guy that gave some other help before me said that he separated
the two most of the time. Is there a benefit to doing it either way?
It seems like the nature of this object oriented programming would make
you want to put the data source in an external object, but I suppose it
is just personal preferences.
>
>
mmalc
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Thanks for all the help!
tyler