Thanks much I'll have a look at that example in more detail to see if I can make that work for what I need to do.
My case is sort of the reverse of that...in that by default the scroll is at the bottom...new messages go to the bottom of the list...so it's like a 'tail' viewer always watching the latest messages. So I need to remove the old messages and only show them if they scroll up to see them. I have something partly working...I remove old DOM elements after a certain point and then put them back when they scroll to the top. But I have two problems to resolve: 1. The scrollbar 'looks' wrong because since I take out old messages the scrollbar thinks the client height is always small so the scrollbar thumb is way too big and doesn't reflect the large content the client really can have. 2. Because of #1 I don't have a good way to tell the user there are more old messages that could be added to the view...currently I just re-add 10 old messages every time they scroll to the top but that needs improvement. It's like I really need a virtual scrollbar that I position and control is size and position based on the actual message content I have vs. what the HTML widget is currently showing. Regarding performance, I think I do need to implement this because I'm seeing very bad memory usage with thousands of DOM nodes...power considerations don't matter much to me...as this will be run in desktop browser. Thanks, -Dave On Aug 14, 9:16 am, Jens <[email protected]> wrote: > You don't have to know how tall each HTML portion is. You just need to know > when to load the next page of data and that would be if your scroll > position nearly reaches the bottom of ScrollPanel. > > Its pretty similar to what you can see here (see > ShowMorePagerPanel.java):http://gwt.google.com/samples/Showcase/Showcase.html?locale=en#!CwCel... > > So you just need a ScrollPanel with a ScrollHandler attached that notifies > you when to load/render the next page of log entries because the user has > nearly scrolled to the end of the displayed widget. > > I have implemented a list some time ago (before cell widgets) that required > fixed height list entries and only rendered the list entry widgets when > they are actually visible to the user. So at any time during scrolling the > DOM only contained that much elements needed to fill the visible area. > Scrolled out items were removed from DOM while scrolled in items were > attached constantly while scrolling. The math wasn't that complicated and > it works pretty well but because of the constantly deleting and adding of > DOM elements while scrolling we had some hiccups in older IE's when > scrolling fast through the list. But we could easily scroll through > thousands of list entries while only having ~40 DIVs (depending on list > height and fixed list entry height) to represent them. > > Although it worked I think I wouldn't do it again that way unless you have > some memory constraints (mobile devices) and don't want to have that many > invisible DOM elements laying around (on the other hand constantly updating > the DOM can cost more battery power on mobile devices). > > Having a ScrollHandler that notifies you when reaching the end of the list > is a simpler solution. > > -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
