Recently, Richard Gaskin wrote: >>>> As other folks have pointed out, it is indeed possible to script a >>>> solution, >>>> but the consistent problem is that the text lines can often be seen moving >>>> slightly out of sync with the stripes. An alternate workaround is to use a >>>> scrolling group which includes a field and a stripe image, which should >>>> prevent any latency while scrolling, but it would be much preferable to >>>> have >>>> an engine-level solution for fields. >>> >>> Agreed, but the nice thing about X's solution is that it's the simplest >>> I've seen yet -- just one extra object! >>> >>> It uses a second field below the top one, with the hilitedLines set to >>> all even numbered lines. You can change the hiliteColor to whatever you >>> want, and by being just one extra object it greatly reduces the "scroll >>> synch" issue you'll find more noticeable with groups. >> >> >> Maybe I'm missing something: if multiple items are scrolled within a group >> by the group's scrollbar, how is there any synch problem? > > When they're all grouped together, the problem isn't synching. > > Instead, the problem becomes one of smooth scrolling. Because fields > are more specialized than groups, they're buffering is apparently > handled in a much more optimized way. For short lists one may never see > the difference, but with very long lists you'll find the responsiveness > of groups lags way behind fields.
(I'm going to out-quote you... :-) OK, when the fields are grouped together you can get performance issues, and when they're not grouped together you synch issues, so it would seem an engine-level solution is still really what is needed here. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
