Table View Blues
Table View Blues
- Subject: Table View Blues
- From: Rixstep <email@hidden>
- Date: Mon, 18 Nov 2002 05:28:04 +0000 (GMT)
The table view (NSTableView) is, in my humble opinion, one of the
most important of all GUI controls. When you start interfacing with
databases, its use becomes vital. But there seems to be a lack of
flexibility with regard to the Cocoa NSTableView. Let me explain by
first explaining what I am used to, and then by explaining what I
perceive as the issues with the Cocoa implementation.
[I am sure I would find the answers to many things if I just "kept
at it" - that goes without saying - but if someone with the
experience I do not have would like to comment, I would be most
grateful.]
* * * * *
In the world of Windows, the corresponding control, the listview,
can be used in one of two ways. First, it can itself hold onto all
the strings put into it. There are messages that can be sent to it
to retrieve data for any row at any column. This method is not often
used, as sorting becomes impossible other than by column 0, the
default. Second, the program itself can hang onto the data, and upon
request give the data to the listview. And if the program itself
hangs onto the data, then the program itself can arbitrarily
determine how the various columns are to be sorted - and not just
according to currency, date, and the like. The program can truly
determine the sorting order itself.
The key here is that with each "list view item", i.e. complete row,
i.e. record, one may associate an arbitrary 32-bit value, and this
32-bit value can be used to store a pointer to a dynamic allocation
which holds the actual record.
The MO is therefore elementary. Read in a record from disk, allocate
memory for it, inform the list view there is yet another record, and
so forth. And this affords me the necessity (hardly a luxury) of
using a platform-independent format (which NSData and coding would
not) such as CSV or TSV. Read a new record, hit the first comma,
that's the end of the first field, hit the next comma, and so forth,
until I've reached a newline or EOF - end of record. Can't be
simpler.
Things get better. Because of the way "heaps" were organized by Dave
Cutler (something this good would hardly have come from the
Microsofties), it takes a single function call - a very low overhead
duh - to completely destroy (completely free) an entire heap. If you
have thousands of records/items pouring into a list view / table
view, it is going to take time to populate the view; if it takes
almost as long to vacate it, you're in trouble. Some programs I run
can count on 20,000 or more records which the user expects the
programs to load in under a second in real time. Switching between
one file and another becomes problematic if the former file's memory
cannot be cleared "in a flash". Fortunately, the "heap" thing comes
to the rescue. Each time a new file is started, the heap used for
all allocations is destroyed (in one API call), a new heap is
created, and all new allocations begin there. Easy peasy.
An added treat is that a single call to the list view can tell it to
completely destroy all items (records). As I no longer need any
associated data - as I can just destroy the heap all the data was
allocated on - this is no mess; in fact it's the call before the
call to destroy the heap, "just in case".
Moreover, I can make sure this does not look ugly to the user. I can
set a "redraw" flag off for the listview while I am doing this - and
because the listview knows it is temporarily freed from the
responsibility of drawing everything on screen, unloading and
loading again goes hundreds of times faster.
So in an effectively infinitesimal period of time, with two API
calls, I can completely destroy all records in any list view / table
view, no matter how many there be therein, and free the associated
memory too. "In a flash, they're gone." And I suggest this becomes
vital when dealing with data arrays even more bulky, such as
customer databases et al.
* * * * *
With the NSTableView, the delegate idea requires my program - my
controlling class - to maintain a mutable array with all the
records. (This is how I was taught at any rate.) It is perhaps not
going to take any longer to create these record instances for each
record I read in from file, but I think it is definitely going to
take a longer time to dealloc them when the user switches files. I
am going to get separate messages sent for every record in my table
view - with populations exceeding 20,000 records, this is a lot of
CPU, a WHOLE lot.
Even if I could associate data - without creating a class, something
I would prefer, as this is just cold data to me and it's going to
have to be formatted as CSV or TSV - with each record in a table
view, I would still be stuck - or so I think - with individual calls
to free() whenever my user wanted to start a new file.
* * * * *
I could attack the problem by using the "zone" functions.
NSCreateZone
Creates a new zone.
NSZone *NSCreateZone(unsigned int startSize, unsigned int
granularity, BOOL canFree)
This would give me somewhere to put my record allocations. But the
converse call:
NSRecycleZone
Frees memory in a zone.
void NSRecycleZone(NSZone *zone)
Has this caveat:
Discussion
Frees zone after adding any of its pointers still in use to the
default zone. (This strategy prevents retained objects from being
inadvertently destroyed.)
Meaning I am still stuck with deallocating everything myself -
otherwise I am going to get one monstrous (and continually growing)
memory leak.
And NSZoneFree, as I understand it, is not what I am after either...
And even if there were a way to get all the memory freed in one fell
swoop, I would still need a way of vacating the table view in the
same short period of time...
Unless it's just a question returning "no rows in table view" and
making sure the question is asked... But I don't know, that just
sounds wrong, "sloppy" - but I just don't know...
As things stand, it seems like the NSTableView is shooting
butterflies with a cannon...
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
_______________________________________________
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.