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 <[EMAIL PROTECTED]> 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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
