Table View Blues
-
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 | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sunday, November 17, 2002, at 10:28 PM, Rixstep wrote:
> 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 have no actual experience programming with very large # of rows in
NSTableView or on Windows, but it's an interesting question so what the
heck...
I think your question could be recast as "How do I implement a very
fast NSTableDataSource in Objective-C without the bottleneck of
alloc-ing and dealloc-ing thousands or millions of records and stuffing
them into a NSMutableArray?"
Here are some other thoughts:
NSTableView will be perfectly happy, and quick, (I think I haven't
tried it) if at one moment, the data source says -
numberOfRowsInTableView: = 100,000, and then you do
/* suppose loadAnotherRecord deallocs 100K records and loads another
500K */
[dataSourceObj loadAnotherRecord];
[tableViewOutlet reloadData];
The bottleneck in the above two lines is going to be how fast your
dataSourceObj can do the unload & reload, not how fast the
tableViewOutlet reload. In the worst case the NSTableView is releasing
(just a retain count, not dealloc-ing anything) all the objects it has
gotten from tableView:objectValueForTableColumn:row: and then
NSTableView is redrawing itself. So the bottleneck would still be with
the data source, not the NSOutlineView.
The NSTableDataSource protocol cleanly separates the data and the
tableview using the MVC pattern (model, view, controller). Maybe that's
what you meant by "MO"; model object?
NSTableDataSource doesn't say anything about how the data source should
be implemented, just that the data source object implementing
NSTableDataSource must respond to those messages. So your data source
object need not internally use a NSMutableArray for records. It could
even lazily read records as needed off disk using whatever portable
file format you are using. It could use C arrays, C++ STL containers,
or a database library, instead of ObjC containers for implementing the
structure of the records and record access.
However, I do think that using ObjC container classes like
NSMutableArray would be the best way to implement the data source for
most developers initially unless one find performance to be
unacceptable with all those objects getting alloc-ed and dealloc-ed
when files are opened and closed. So it seems you have enough records
to hit that bottleneck.
Also maybe consider using -noteNumberOfRowsChanged on NSTableView as it
allows you to display data to the user while more records are being
loaded. Might be useful if you are constructing objects to stuff into a
Alex Rice <alex...>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, November 18, 2002, at 12:54 AM, Alex Rice wrote:
> /* suppose loadAnotherRecord deallocs 100K records and loads another
> 500K */
> [dataSourceObj loadAnotherRecord];
Oops, that doesn't make sense. Rather it would [dataSourceObj
loadAnotherTable]; or [dataSourceObj loadAnotherDatabase], not
loadAnotherRecord.
> [tableViewOutlet reloadData];
Alex Rice <alex...>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am Montag, 18.11.02 um 06:28 Uhr schrieb Rixstep:
> With the NSTableView, the delegate idea requires my program - my
> controlling class - to maintain a mutable array with all the
> records.
As Alex already pointed out, the table view does not care how you
maintain your data.
You simply get a request for the contents of any cell that's about to
be displayed and tell the table view what it should put there.
> I am going to get separate messages sent for every record in my table
> view
You will only get messages for those cells that are actually being
displayed, AFAIK.
> 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 don't understand. If you would like to allocate one big chunck of
memory and manage it on your own - go ahead. Nothing is going to stop
you. Objective-C is a superset of C after all.
bye. Andreas.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
--- j o a r <joar...> wrote: > How often would you replace the contents of the table view? If you
>
> switch the contents of the table view so often that memory
> allocation / deallocation is a serious bottleneck, don't you
> think that this would cause the table view in itself to be
> almost useless as an UI element?
Absolutely not. I have several examples where it not only is necessary, but works fine - given the memory stuff I can use where I have recently been.
> What would happen when the user is scrolling through the table
> view, looking for something or keeping a selection, et.c., and you
> switch the data?
I don't switch data - the user does. The user cannot switch data and scroll at the same time. I agree that this seems unfeasible with the NSTableView, but it shouldn't be - and it isn't, on other platforms.
> I'm not sure that I agree with using just one table view for
> displaying 20.000 records
20,000 is an example. Most real life situations will require a lot more.
> it would be rather difficult to navigate
Not as things stand at the present - on the other platform. There is nothing difficult about it at all.
> Have you benchmarked this? Where's the bottleneck?
Don't need to. There is too much happening. Correction: there is _something_ happening, whereas where I have been there is nothing. Two calls and that's it: vacate the view, and good-bye to all data. Two (2) calls.
The bottleneck is naturally in the recursive deallocs, for each string for each column for each row in the view.
> Here's a short snippet to read a comma separated file to be used
> for a table view:
>
> - (void) loadTableDataFromFile:(NSString *) path
> {
> NSString *str = [NSString stringWithContentsOfFile: path];
> NSArray *arr = [str componentsSeparatedByString: @","];
>
> [myTableViewArray setArray: arr];
> [myTableView reloadData];
> }
>
> No error checking, no sorting, et.c., but you get the idea...
Yes, this is very cool, but it's not on the upside that the problem occurs. We all know we have to get the data in there. What we cannot afford is a haphazard memory arrangement so we're spending as much time getting rid of it later.
> I would suggest reading and parsing files in a separate thread if
> the responsiveness of the GUI is important.
For what today is at most a one second delay, I hardly think this is justified.
> That said, NSTableView is provided as a general purpose control -
> not suited for very large tables with a high frequency of updates.
OK, fine, sure. Then what control does NS have for large tables?
> the main limitation is that you can only choose to update the
> whole table view, and not just a given x,y cooordinate in the
> table through the public API of NSTableView
I'm prepared to accept this. In both models, the drawing of the view is left to the view itself, and the application responds to needs for data to be displayed. That's the view's problem, but I've never seen a view hiccup for that...
> In our main application we've created our own table view optimized
> for our particular needs and this might be something that you need
> to do if NSTableView cannot keep up properly.
Yeah, I'm getting that picture. My complaint isn't so much with the view itself, but with the lack of tidy memory management underneath. That's where the clocks are saved.
The picture I am getting is that Apple/NS are unsurpassed at graphics, but that types of business things are a bit unfamiliar for them. I would hate to give MS the win on this one, but it looks like their crummy listview, coupled with Cutler's memory management, wins this round.
Unfortunately. ://
Cheers, R.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> 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 don't understand. If you would like to allocate one big chunck of
> memory and manage it on your own - go ahead. Nothing is going to stop
> you. Objective-C is a superset of C after all.
No, I don't think you do. Sorry if I was unclear.
It's got nothing to do with languages. It has a bit to do with the API. But mostly it has to do with the underlying memory management in the operating system - or any layer thereof the API wants to put on top.
In Unix, AFAIK, calloc and malloc are true primitives, whereas in Cutler's Win32 they are not - they resolve to his own memory management schemes - which in this case are essential to survival.
You can never get away from the task of loading data into a program. What you must get away from here is the bottleneck of having to deal with potentially 100's of 1000's of recursive dealloc calls when a view is to be vacated and repopulated.
Cheers, R.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
> Do your own control, if you think that is the problem...
That's downright ridiculous.
> Well, the point is that a table view isn't necessarily the most
> suitable user interface element for that kind of need...
And "that kind of need" is a _very_ common business kind of need - so what does Apple have instead?
> Ok, lets assume you have 50000 records in your table view.
This is about scrolling. The issues I mentioned have nothing to do with scrolling. Read it again.
> DIY. The framework can't do everything for you.
This is downright ridiculous. What's worse, it's lame.
> For a consultancy fee, I assure you there are many people
> (incidently
> including myself ;) who would help you optimize your code if you
> are not
> able to do it yourself.
Oh drop it. From the tone of your letter, it's obvious you know even less about Cocoa than the rest of us. Go play and be rude somewhere else.
R.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, November 18, 2002, at 05:43 AM, <rixstep000...>
wrote:
> Yes, this is very cool, but it's not on the upside that the problem
> occurs. We all know we have to get the data in there. What we cannot
> afford is a haphazard memory arrangement so we're spending as much
> time getting rid of it later.
Someone suggested to me off-list that NSTableView might not retain
objects it gets from the NSTableDataSource. If that's true then the
bottleneck is completely in the data source implementation and has
nothing to do really with the table view itself.
If your data has 1M rows, don't create 1M NSStrings when the data
source object is created, as the previous loadTableDataFromFile:
example would do. Instead create the NSStrings lazily.
The tableview will only request objects from the data source _when it
needs to display them_. The user can view at most 100 or so rows at
once, and there is no problem creating 100 NSStrings it won't even be a
noticable hit creating them every time the user scrolls. Actually only
1 NSString would be created each time your
tableView:objectValueForTableColumn:row: is called. Something like this:
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex
{
NSString *answer = [NSString stringWithCString:
someReallyFastFnToReadCSVData( rowIndex, [aTableColumn identifier]
)];
return answer;
}
If you implement it this way I suspect your performance concerns will
disappear. I might try this later on because I am curious :-)
Alex Rice <alex...>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am Montag, 18.11.02 um 14:10 Uhr schrieb <rixstep000...>:
> What you must get away from here is the bottleneck of having to deal
> with potentially 100's of 1000's of recursive dealloc calls when a
> view is to be vacated and repopulated.
Hm. Then why don't you use your own memory management?
A problem could occur if the table view buffered all cells it had
displayed at some time. I'm not sure if it does; but even then you
could probably write a subclass that doesn't.
> coupled with Cutler's memory management,
Well, can't you get that converted to the Mac? If it's written in C
this should be possible.
bye. Andreas.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, Nov 18, 2002, at 13:43 Europe/Stockholm,
<rixstep000...> wrote:
>> I'm not sure that I agree with using just one table view for
>> displaying 20.000 records
> 20,000 is an example. Most real life situations will require a lot
> more.
As long as you don't turn into that guy over at Mac OS X Dev that
wanted to display 37 million rows in a table view... ;)
(Thread: "Maximum size for NSTableView?")
>> That said, NSTableView is provided as a general purpose control -
>> not suited for very large tables with a high frequency of updates.
>
> OK, fine, sure. Then what control does NS have for large tables?
NSTableView is the only one - but I wouldn't nessecarily rule it out
already.
>> In our main application we've created our own table view optimized
>> for our particular needs and this might be something that you need
>> to do if NSTableView cannot keep up properly.
>
> Yeah, I'm getting that picture. My complaint isn't so much with the
> view itself, but with the lack of tidy memory management underneath.
> That's where the clocks are saved.
>
> The picture I am getting is that Apple/NS are unsurpassed at graphics,
> but that types of business things are a bit unfamiliar for them. I
> would hate to give MS the win on this one, but it looks like their
> crummy listview, coupled with Cutler's memory management, wins this
> round.
Weren't the Cocoa frameworks created for use in the enterprise? I know
that we've successfully used them for heavy lifting for years and years
on a wide variety of platforms - still going strong actually - and the
streams of data we have to deal with in real time is quite something.
I think that Alex and Andreas suggestions on memory management might be
a good thing to look into. Is the memory management "a la Cutler" you
mentioned a Windows only thing, or something that you could use also on
Mac OS X?
j o a r
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
NSTableView reuses one cell per column for the drawing of all rows, so
I don't think that's a problem.
j o a r
On Monday, Nov 18, 2002, at 22:07 Europe/Stockholm, Andreas Mayer wrote:
> A problem could occur if the table view buffered all cells it had_______________________________________________
> displayed at some time. I'm not sure if it does; but even then you
> could probably write a subclass that doesn't.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>>> switch the contents of the table view so often that memory_______________________________________________
>>> allocation / deallocation is a serious bottleneck, don't you
>>> think that this would cause the table view in itself to be
>>> almost useless as an UI element?
>>
>> Absolutely not. I have several examples where it not only is necessary, but
>> works fine - given the memory stuff I can use where I have recently been.
>
> My point (usability issues ignored, for the time being), is that you can use
> what ever storage and allocation method you want. For example, you could use a
> linked list in C code, for which you are responsible of all memory management.
> The actual allocation is not a siginifiant bottle neck in most cases, but
> retain/release may be. Many else have pointed this out.
>
> In the data source, you then provide the information required by the control.
> That is seldom more than 200 cells at a time, and that happens in a quite
> short time, and is not dependant of the size of the underlying data set.
>
> / Sincerely, David Remahl
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, November 18, 2002, at 03:49 PM, j o a r wrote:
>>> I'm not sure that I agree with using just one table view for
>>> displaying 20.000 records
>> 20,000 is an example. Most real life situations will require a lot
>> more.
>
> As long as you don't turn into that guy over at Mac OS X Dev that
> wanted to display 37 million rows in a table view... ;)
>
> (Thread: "Maximum size for NSTableView?")
Not so fast; I'm lurking over here too, but I wasn't going to bring up
that thread. At least now I've got company in the "pathological
NSTableView users' set". ;)
- - - - - - - - - - - - - - -
Terrence Asselin
RiskWise LLC
- - - - - - - - - - - - - - -
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
At 23:34 +0100 on 11/18/02, j o a r wrote:
> NSTableView reuses one cell per column for the drawing of all rows,
> so I don't > think that's a problem.
And to veer off on to a new topic... I'm doing some work with an
NSTableView and I"m trying to figure out if there is a way to get
what amounts to cell by cell access. Basically I'd like to make a
table that looks like this:
Stuff 1 Stuff 2
blah NSPopupButton for blah
blah2 NSPopupButton for blah2
blah3 NSString for blah3
blah4 NSString for blah4
or alternatively have a different popup button menu for blah3 & blah4
than for blah & blah1. Any thoughts?
--
_____________________________________________
Kevin Elliott <mailto:<kelliott...> ICQ#23758827
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, November 18, 2002, at 04:23 PM, David Remahl wrote:
>> My point (usability issues ignored, for the time being), is that you
>> can use
>> what ever storage and allocation method you want. For example, you
>> could use a
>> linked list in C code, for which you are responsible of all memory
>> management.
>> The actual allocation is not a siginifiant bottle neck in most cases,
>> but
>> retain/release may be. Many else have pointed this out.
>>
>> In the data source, you then provide the information required by the
>> control.
>> That is seldom more than 200 cells at a time, and that happens in a
>> quite
>> short time, and is not dependant of the size of the underlying data
>> set.
>>
This has been an interesting through and I just want to recap what has
been said, and point out that one of Rixstep's main questions hasn't
been answered.
1) Does Unix/BSD/OS X have the equivalent functionality of Win32's
HeapCreate, HeapAlloc, HeapDestroy? If no, what is the C programming
method used instead?
1a) Rixstep thinks that the absence of these functions is going to
prevent him from writing a NSTableDataSource that will be as quick as
the Windows implementation of a tabular browser for many K's of rows.
Is this as much of a bummer as he thinks?
1b) Maybe this is a question for asking on Usenet in comp.lang.c or
something? This just occurred to me: it's likely the answer can be
found in the source to the WINE project which is basically an
open-source Win32 runtime for Linux.
--
2) The MVC pattern and NSTableDataSource protocol are a help not a
hinderance and don't prevent Rixstep from writing the backend in as
gnarly C code as he wants to. :-)
3) The NSTableView, and most everything in Cocoa, buffers the display
so one generally doesn't need to worry about locking for redraws like
one would on Win32.
4) NSTableView itself is doing nothing to hurt performance. Because of
the MVC pattern, the NSTableView ONLY sees objects for which is will
actually display. It doesn't do anything to those objects which is
going to slow you down. Any bottleneck is in the NSTableDataSource
implementation.
HTH
Alex Rice <alex...>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday, Nov 19, 2002, at 12:27 US/Eastern, Kevin Elliott wrote:
> At 23:34 +0100 on 11/18/02, j o a r wrote:
>> NSTableView reuses one cell per column for the drawing of all rows,
>> so I don't >think that's a problem.
>
> And to veer off on to a new topic... I'm doing some work with an
> NSTableView and I"m trying to figure out if there is a way to get what
> amounts to cell by cell access. Basically I'd like to make a table
> that looks like this:
>
> Stuff 1 Stuff 2
> blah NSPopupButton for blah
> blah2 NSPopupButton for blah2
> blah3 NSString for blah3
> blah4 NSString for blah4
>
> or alternatively have a different popup button menu for blah3 & blah4
> than for blah & blah1. Any thoughts?
Subclass NSTableColumn, so that you can set different cells for
different rows.
- --
http://homepage.mac.com/clarkcox3/
<clarkcox3...>
Clark S. Cox, III
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)
iEYEARECAAYFAj3aqxIACgkQd6STocYT1xXIFwCdG8MsGHf21EQvzsa+vGfLza8h
nNgAnjCTFwlPzacssURJipULNNUrbqHq
=CfsF
-----END PGP SIGNATURE-----
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'm trying to display some fonts in an NSTableView and NSOutlineView
but having some problems with the baseline (I think that's what it's
called) and fonts getting chopped off. You can see in the screenshot
at http://www.unsanity.org/rosyna/fontissue.png
Is there anyway to fix this? I'm setting the attributed string in the
objectValue delegate method for each table. I've also noticed
scrolling is extremely slow when showing the fonts. But the cutting
off and the odd font alignment is what really worries me.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
---
Please include any previous correspondence in replies, it helps me
remember what we were talking about. Thanks.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
