Scrolling a group with a very long field - basic concept?

[AxWald]

Hi,

looks like I'm blocked - I cannot wrap my brain around this:

I have a field with a very long text to scroll. It has a formattedHeight in the 200Ks. Using a normal scrolling field works fine, it scrolls all the 7K+ lines.

But this should work on mobile, too, so I need it in a scrolling group. I did:

• Make sure the grp & the fld have the same rect.
• Make sure the grp has "lockLoc" & is "scrolling".
• Make sure the group has a scrollbar, and the field has none.
• Set the height of the fld to the formattedheight of it (and adjust the top).
• Set the boundingRect of the grp to the rect of the fld.

Now I should have the group as a "window" to the much longer field, and can scroll the field "below it".
(For mobile I'd later mean to set a mobileControl/ scroller on top of the grp.)

Works so far - BUT:
The field content is cut short at a formattedHeight of 32,767. Max value for the field height. OUCH!

What I'm doing wrong? Is there a solution (short of swallowing a field heigth of max. 32,767)?
And what exactly is this "boundingRect", do I need it at all? I've read all I found about it, but it doesn't give me a real understanding :/

Thx for any help, and have fun!

[dunbarx]

Hi.

Maybe just load continuously from another repository, like a custom property. Push the next line up from the bottom when scrolling down, and down from the top when scrolling up. That way the field contents are never more than the trivial amount one can see directly on screen.The scrollbar may have to then be an entirely separate control, unattached to the field itself.

Sound like fun. I will try it and get back to you.

Craig

EDITED, stay with what you see above.

[dunbarx]

Hi.

This took only 15 minutes. It is a little wordy. Make a field and a scrollbar. Set the rect of the scrollbar so it is vertical, about 16 pixels wide, and the height of the field. Set the scrollbar to the right of the field. Put hundreds of lines of text into the field in any convenient way. Explicitly set the textHeight of the field, to, say, 16. Set a custom property, "the scrollContents" of the field to the text of the field.

Put this into the scrollbar script:

Code: Select all

on scrollbarDrag newPos
   put newPos / the height of me into tRatio
   put the number of lines of the scrollContents of fld 1 into totLines
   put tRatio * totLines into startLine
   put line startLine to startLine + 16 of the scrollContents of fld 1 into fld 1
end scrollbarDrag

This needs a little tweaking here and there, for example to properly set the display all the way to the bottom of the field, but that would have taken another good five minutes, and I have a lunch date.

Craig

[richmond62]

Tangentially . . .

What with processors being what they are nowadays,

might it not be possible to remove that 32,767 limit?

[AxWald]

Hi Craig,

I see where you're going. It occurred to me that I'd have to exchange the fields contents as soon as I approach the dreaded 32,767 px limit.

But this rather spoils my whole concept - what I'm working on is basically a self contained table field for selecting from or composing data sets. It's created on the fly and has any data /settings fed to it via custom props (loc, size, tabs, font, header values, names of handlers for external filters, line selects, R-Clicks, etc. ...)
It comes with a header field (that sorts columns), has single- or multi line select, and a built-in footer field with a "select all/ none" control, a simple filter opportunity (name contains ...) and some more stuff.

Alone keeping track of multi line selects looks like a nightmare when switching out the content, and this would add serious calculation cycles, for sure.
And - how then would this work on mobile?

Guess I'd rather limit the max. line count. There's only one instance yet where I hit the wall (above 1.1K lines in this setting), and with a bit of magic I can enforce a mandatory filter that will keep the line count manageable. Not nice, but it should do.

But still, there must be another way. It works flawlessly with a basic field (where you don't need to set the field to a size to cover the whole formatted text), it's only when this is put into a scrolling group.

Maybe someone has another idea, or can point me to a misunderstanding of this whole concept.

Thx a lot, and have fun!

[AxWald]

Hi,

[...]might it not be possible to remove that 32,767 limit?

Guess it's much too un-sexy to fiddle with such boring trivialities like fields ...

Note: The current architecture uses 16-bit signed integers for all co-ordinates, which means that the value range is -32768 to 32767.

Well, at least we have now "infinity" as constant ...

Have fun!

[FourthWorld]

Have you tried just putting the scroller over a field without the enclosing group?

Having to add a group is a really, really dumb requirement. And in Android at least, unnecessary.

[dunbarx]

Axwald.

First off, does the actual mechanics work out the way you wanted?

After that, whatever you planned,, to load, edit, delete or whatever to that field, you would simply do also to the property. The mechanics of the scroll are always entirely separate from any of that and stand alone.

There are plenty of messages, the main one perhaps "textChanged", that can update the current instantiation of the field, then update the custom property, and never look back.

Craig

[FourthWorld]

The field is editable? On mobile, scratch everything above and type out a mobile-native field definition with mobileControlCreate.

[AxWald]

Hi,

Have you tried just putting the scroller over a field without the enclosing group?

That's what I'm doing atm. I removed the group containing the field, added a scrollbar & rawKeyDown handlers for mouseWheel to it (that was in the grp previously), and on desktop now it works flawlessly. With all 7K+ lines :)
For trying Android, I'm just hampered with some flaws I introduced meanwhile - so this will take some more time. Guess I'll make a simple try-out stack with bogus data.

I intend to lay a mobileControl "scroller" onto the scrolling field, and to look what happens.
This I'd do in a "setMeUp" handler in the group containing the whole stuff (that runs each time it's shown), and there I'd place scrollerDidScroll, too ("is sent to the object containing the script that created the scroller control").
TouchStart/ End would go into the scrolling field, right?

I'll try to compile a demo stack - it's hard to explain what I'm doing, guess it's more easy to show ;-)

Have fun!

[jacque]

Trevor Devore has written a DataView library, similar to the datagrid, to solve exactly this problem. He offered it to me privately and helped me set it up when I was under a tight deadline, so even now I'm not quite sure how it works exactly. It was only recently adjusted to work on mobile but so far we haven't had trouble with it.

If your other experiments don't work out, you might want to contact him.

[AxWald]

Hi, progress report:

I nearly went mad, couldn't get my head around setting up the dreaded mobile scroller with my work ...
So I simplified it, simplified again, simplified once more, finally dropped all & started over with the very basics
- and finally got it running. What I have now:

• A simple text field for table display (listBehaviour, dontWrap, lockText, vScrollBar, tabStops),
  in the desired size to fit on my card.
• The layer mode is "scrolling". No borders, no graphic effects. No script in it.

Loading 7K lines into it (> 300KB tab-CR CSV) works fine. It shows all data, scrolls smoothly, even mouseWheel works. With a formattedHeight above 210K px :) The same is displayed on Android, but is quite unusable yet.

Next Step: Dropping a mobile scroller on top. I already added this code to the card, now I call it from from a button:

Code: Select all

on mobScrollMake
   set the vscrollbar of fld "data_fld" to false
   set the acceleratedRendering of this stack to true
   put the rect of fld "data_fld" of this cd into theScR
   put 0,0,the width of field "data_fld",the formattedHeight of field "data_fld" into theCnR
   
   put (the short name of this cd) & "TGScroll" into lName  --  so it's unique (only 1 here)
   if lName is in mobileControls() then
      mobileControlDelete lName
   end if
   mobileControlCreate "scroller", lName
   put the result into lScID
   --  error checking omitted
   mobileControlSet lScID, "rect", theScR
   mobileControlSet lScID, "contentRect", theCnR
   mobileControlSet lScID, "scrollingEnabled", true
   mobileControlSet lScID, "vIndicator", true
   mobileControlSet lScID, "vscroll", 1
   mobileControlSet lScID, "visible", true
end mobScrollMake

on scrollerDidScroll hOffset, vOffset
   set the vScroll of fld "data_fld" of this cd to vOffset
end scrollerDidScroll

And - runs like a charm!
Well, it takes some serious swiping to reach line 7000, but it's there. And the scrolling is beautifully smooth. Even on an antique MediaTab with Android 4.4 & 1GB RAM (left over test crap from a customer).
I don't know how much of the above is Voodoo. The "acceleratedRendering" is important for sure, w/o the scrolling works, but is rather slow.

Now, it's proven that we don't need a group to make a functional scrolling field for Android, as Richard suggested. A field that can display as many lines as RAM & CPU/GPU allows ;-)
I'll now slowly port back all of my other stuff, but it seems it can be done. ;-)))
When ready I'll post the demo here.

Have fun!

[AxWald]

Hi, appendum:

Adding a border to the scrolling fld doesn't hurt the performance.
Adding graphic effects (dropShadow, innerGlow) does - it's noticeable slower then.

Adding a group to the field makes no difference now - still speedy!
Adding graphic effects/ border to the group gives the same slowdown as above.

Moving the whole mobileControl code (as above) into a button still works, doesn't have to be on a card then - good, I may want more than 1 scroller on a card ;-)

Guess I'll decouple my data field from its group (with the other controls) & just place it above it.
And then drop the mobScroller on top. Tested: Works!

Future looks a lot brighter now :)

Have fun!

[dunbarx]

Hi.

Glad you worked through it.

I do not develop for mobile, but am interested where this:

The field content is cut short at a formattedHeight of 32,767. Max value for the field height. OUCH!

came from. This seems like a physical limitation, not a limit on the maximum contents of a field. Was it never actually so, or was it not ultimately pertinent?

Craig

[jacque]

I used to use a scroller over a field all the time and mentioned to Mark Waddingham that it worked. His reply was, "did I put that in?" LOL. However I did notice later that scrolling a group seemed smoother on some devices (particularly Android) so I've been converting everything to groups lately. But most of my earlier apps scrolled plain fields.

That said, I did run into the text limitation on field content in my last project and the only solution was to implement Trevor's DataView. The text limitation is based on character count rather than lines of text. I'm curious how many characters are in the 7k lines you had.

Edit: You only need to set acceleratedRendering once in a preOpenStack or preOpenCard handler. I'm not sure if reseting it constantly in the scroller creation will cause delays. Probably not, but it's redundant. Also, remember to delete all native mobile controls on closecard., otherwise they will appear on every other card and can cause issues. Native controls are overlays on top of the whole stack and don't go away until you delete them.