norman@d.cs.okstate.edu (Norman Graham) (04/03/91)
I have a colleague that needs to provide a scrollable view for a
special kind of container object. This container object is unique
because it doesn't know how big it is or how many elements it contains,
but it can return the element that is say 33% from the beginning
of the container. (When asking for an element based on a percentage,
the container can only take a guess which, in extreme circumstances,
can be way off.) The container also has a notion of a current element and
can get the previous, next, first, and last elements; so in theory
you could count all the elements, but in practice that would take far
too long.
My colleague would like to create a subclass of TScroller that can
scroll views of these container objects, but he can't find a class
definition that cleanly describes what he needs. In short, his definition
requires the scroller object to communicate directly with the container
object. The view that sits on the scroller object also communicates with
the container object (you would expect this). BTW, since the size of
the container object is indefinite, the container view has to be either
the same size as the scroller or the maximum possible view size.
Would anyone care to enlighten us on how this should be done?
--
Norman Graham
<norman@a.cs.okstate.edu> Standard Disclaimer Applies
{cbosgd,rutgers}!okstate!normanml27192@uxa.cso.uiuc.edu (Mark Lanett) (04/03/91)
norman@d.cs.okstate.edu (Norman Graham) writes: >I have a colleague that needs to provide a scrollable view for a >special kind of container object. This container object is unique >because it doesn't know how big it is or how many elements it contains, >but it can return the element that is say 33% from the beginning >of the container. (When asking for an element based on a percentage, >the container can only take a guess which, in extreme circumstances, >can be way off.) The container also has a notion of a current element and >can get the previous, next, first, and last elements; so in theory >you could count all the elements, but in practice that would take far >too long. >My colleague would like to create a subclass of TScroller that can >scroll views of these container objects, but he can't find a class >definition that cleanly describes what he needs. In short, his definition >requires the scroller object to communicate directly with the container >object. The view that sits on the scroller object also communicates with >the container object (you would expect this). BTW, since the size of >the container object is indefinite, the container view has to be either >the same size as the scroller or the maximum possible view size. >Would anyone care to enlighten us on how this should be done? >-- >Norman Graham ><norman@a.cs.okstate.edu> Standard Disclaimer Applies >{cbosgd,rutgers}!okstate!norman I haven't (fortunately) needed to subclass TScroller yet, so I don't know what I'm talking about :-) but... 1) it seems that if the view can deal with things properly, scrolling should work automatically. How do you draw your view when you get an area? If you just have have an arbitrarily sized view, then you interpolate the area received to determine your percentages, and draw items starting from there. It seems nasty, though, since scrolling could cause one item to be listed twice, or not at all, depending on how sensitive your "guessing" is. 2) If you must, connecting the TScroller to the container isn't that bad. This makes things easy since when you get a scroll down you know to just increment and go draw the "next" element--no saying "where am I". In this case the scroller tells the view exactly what to draw rather than sending an update. 3) Must you display the list directly or could you pull sublists out based on some criteria and display them? -- //----------------------------------------------------------------------------- Mark Lanett ml27192@uxa.cs.uiuc.edu
norman@d.cs.okstate.edu (Norman Graham) (04/04/91)
From article <1991Apr3.061733.18937@ux1.cso.uiuc.edu>, by ml27192@uxa.cso.uiuc.edu (Mark Lanett): > 1) it seems that if the view can deal with things properly, scrolling should > work automatically. How do you draw your view when you get an area? If you > just have have an arbitrarily sized view, then you interpolate the area > received to determine your percentages, and draw items starting from there. It > seems nasty, though, since scrolling could cause one item to be listed twice, > or not at all, depending on how sensitive your "guessing" is. No, the guessing may not be good enough to display an area based on an update rectangle. The container class is just too dumb: I just can't understand why the original designers didn't think about counting the elements when they built the data structures. :-( > 2) If you must, connecting the TScroller to the container isn't that bad. This > makes things easy since when you get a scroll down you know to just increment > and go draw the "next" element--no saying "where am I". In this case the > scroller tells the view exactly what to draw rather than sending an update. Yes, this is the current scheme: The scroller object doesn't invalidate a rectangle on the container view; it just asks the container view to draw the next/previous element or to draw several elements based on the current thumb position. > 3) Must you display the list directly or could you pull sublists out based > on some criteria and display them? The sublists must be displayed directly: There's no opportunity to create a new container object that knows it's number of elements. Thanks for the comments. Norm -- Norman Graham <norman@a.cs.okstate.edu> Standard Disclaimer Applies {cbosgd,rutgers}!okstate!norman