number of columns in a table field
jonathandlynch at gmail.com
Wed May 31 11:35:41 EDT 2006
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
> > 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
> 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:
More information about the Use-livecode