limitation on vScroll?

Josh Mellicker josh at dvcreators.net
Thu Jan 25 16:55:45 EST 2007


I have a large scrolling group.


If I set the vScroll of this group to 32780 (or any smaller number),  
no problem, works perfectly.

If I set the vScroll of this group to 32781 (or any higher number),  
the vScroll is set to zero (and the group scroll jumps to the top).

Not sure if this has anything to do with the below, just thought I'd  
include it in the off chance...


So, anyone know wat up?




On May 31, 2006, at 8:24 AM, Richard Gaskin 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




More information about the use-livecode mailing list