Synchronous scrolling Solved

[Scott Rossi]

Recently, DunbarX at aol.com wrote:

> Groups, always groups. Thanks. Works fine, but differently.
> 
> When scrolled, the fields themselves are viewed as if they are under a
> "window", as if they were actual scrolls unrolling under a fixed viewing area.
> I 
> guess this actually makes sense. My flds overlap their scrollbars so only
> the righthandmost is visible, and the thumb actually is moved out of the
> "picture" as the group scrolls. I cannot see that this loses anything in the
> translation, but it is not a true synchronous scroll.

I disagree -- a group is more like putting the fields in a box -- you can
still access them the same as if they were separate objects, but they are
moved around inside a frame of sorts.

Regardless, if you really want to keep your controls separate, you can use a
scrollbar adjacent to the fields and set the scroll of the fields using the
scrollbarDrag message.  Execute the following in your message box to see an
example:
go url "http://www.tactilemedia.com/download/scrolltest.rev"


> This is why I have to concentrate on what Rev is, as opposed to how it is
> just a superset of HC.

Definitely.  Coming from an HC background definitely helps, buy you'd do
well to get into Rev methods rather than trying to force Rev to behave like
HC.


> I am surprised at the sluggishness of trapping and processing the
> scrollBarDrag message, given Rev's usual speed.

I don't believe you'll find any sluggishness in the sample stack -- it's
just a different way to do things (Rev often affords several solutions to a
problem).  You can try the lock screen option to see if it makes any
difference on your end -- doesn't do too much here (locking the screen *may*
produce a bit smoother performance) but I didn't do a lot of comparison.

Hope this helps.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design