UI performance and large data set in Table Object
ambassador at fourthworld.com
Fri Feb 22 11:00:34 EST 2008
> As I mentioned in my previous listing, 20, 30, or 50000 lines can be found,
> depends on the users search criteria. My example was 20,844 lines).
> The record length for the table is 255 (counting up the SQL definition
> lengths for all columns)
> On the stack I'm only using 8 of the 13 columns from the SQL table. The
> record length for the Table Field then is 200.
> I also tried the Scrolling Field and compared it to the Table Field, using
> 20,844 lines - big difference, where the Scrolling Field won in it's
> performance of no degradation of stack resize.
> But I've never used this object before, because I lose the formatting of
> columnar presentation.
> If I use this object, is there a way to set it to columnar appearance?
The field object was the key to the recipe I provided in my earlier
post, but when I wrote that I forgot to specify "Any text container
controls other than what the IDE calls a 'Table Object'". :)
The other ingredients in my recipe were to set its hGrid and vGrid
properties. Once you do that, you've just made an engine-native table field.
I don't use the Rev IDE myself, so I've never had occasion to use it's
"Table Object" (I still use the old IDE from before the acquisition,
MetaCard), so I can't guess what it's doing that would eat so much time.
But apparently some of the extra properties they set in it trigger a
lot of other scripts in their libraries.
Does anyone here know what the scripts driving Rev's "Table Object" are
doing that would require so much processing during resizing?
While there may be some room to optimize some of the scripts in the Rev
IDE, I have a *lot* of confidence in the Rev engine. Glad to see you've
found a solution with it that performs well.
Know the engine.
Trust the engine.
Use the engine.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the Use-livecode