number of columns in a table field

[Jonathan Lynch]

Interesting...

And, independent of the the engine's size limit on a subgroup, there is also
the problem of moving around that many objects...

Say you have a pseudo-table with 3000 rows, and you insert a row between
rows 1 and 2 - the engine then has to go through and rename rows 2 through
3000, and reposition them in order to make space for row 2.

This is not instantaneous.


I have thought of another method, using only enough rows to be visible in
the table, and storing all the rest of the data in custom props - then, when
you scroll, it would actually just reassign the information in each row.
Such a thing would be tough to implement so that it actually looks like
normal scrolling, but I think it could be done.


On 5/31/06, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
> Jonathan Lynch wrote:
> > my psuedo-table object works pretty well - Marielle made it available on
> his
> > site. It addresses many of these concerns.
> >
> > However, I would not use it for thousands of rows. For a couple hundred
> > rows, it works ok, but for 2 or 3 thousand rows - well, that is just too
> > many sub groups for the engine to handle quickly.
>
> I've been using nested groups as custom tables for quite some time, but
> curious about the threshold for bad behavior I did some testing:
>
> 1. Make a group -- two buttons, two fields, each 23px high, in a row
> 2. Group it, name the group "record"
> 3. Make a copy of that group, group both groups, and name the new master
>    group "main"
> 4. Make a button with this script:
>
> on mouseUp
>   put 2113 into n
>   --
>   lock screen
>   lock messages
>   --
>   -- delete old groups:
>   repeat with 1 = the number of grps of grp "main" down to 2
>     delete grp 2 of grp "main"
>   end repeat
>   --
>   set the vscroll of grp "main" to 0
>   put 0 into i
>   if the optionKey is "down" then exit to top
>   repeat n
>     add 1 to i
>     clone grp "record" of grp "main"
>     set the topleft of it to the bottomleft of grp i of grp "Main"
>   end repeat
>   --
>   put the formattedheight of grp "main"
> end mouseUp
>
>
> What I found is that the number shown above assigned to N is the max I
> can create here without odd positioning of objects.  If I exceed that I
> start getting row groups positioned over other row groups.
>
> The formattedHeight of the "main" group is shown as 32806 --
> suspiciously close to 32767 (32k), the old buffer limit for QuickDraw.
>
> So this may suggest that the internal routines for buffering groups is
> either using the old QD API, or has internal limits about the same as
> QD's.
>
> It's worth noting that 32,806 is almost 38 feet at 72dpi, which is
> plenty for most uses so I can't really call this a bug.
>
> But it might make a useful enhancement request to explore extending that
> buffer size.
>
> Or would it?  There's already a request for compound-object tables, so
> if that gets done will we need position objects for any other purpose
> farther than 38 feet in either direction?
>
> --
> Richard Gaskin
> Managing Editor, revJournal
> _______________________________________________________
> Rev tips, tutorials and more: http://www.revJournal.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>