The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Implementing unlimited scrolling

I'm building a custom control that is sort of like a spreadsheet grid and sort of like an Outlook calendar. Along the top I have columns of dates. I want to be able to scroll left and right through time with no limit, displaying events that occur on those dates, etc.

I've come up with two possible designs. One is to create new "grid cell" objects as the user scrolls (maybe with some fancy predictive cacheing). The problem is that this will involve a lot of creation and destruction of objects. The other design is to have a static number of columns/rows and scroll the data "through" the cells. When the user scrolls, each cell's date value (and Y-axis value) changes and events on that date shift to the new cell that represents that date. This seems to involve a lot of reassigning values. I'm not sure which is the better tradeoff.

The second choice seems to be the better of the two designs, though I'm not 100% comfortable with it. The viewable grid is a "viewport" into the unbounded universe of possible dates. Why introduce another viewport layer, in the form of a bunch of columns that are outside the visible control area?

Ultimately, what I'd like to have is something like Excel, where you can scroll endlessly down or to the right and it will (at least seem to) create new cells, but if you scroll back up, the grid shrinks back down again to contain only the cells containing data.

Has anyone else run up against this kind of issue? What are your thoughts on implementing unlimited scrolling like this? I'm doing this in Windows Forms 2.0, though I think the concept is platform-agnostic.

Thanks!
Jesse Send private email
Monday, February 19, 2007
 
 
Have a fixed-sized viewport, with just enough view-cells to fill the visible screen (change the number of cells in the viewport when the size of the screen or the size of cells changes).

Have unlimited underlying data (perhaps on disk). Possibly, optimize the data structure for sparse data (so that, if I enter an event for 2036, it can do this without creating storage for umpteen intermediate days).

The identity of the data displayed in each viewport cell then varies with the current scroll position.
Christopher Wells Send private email
Monday, February 19, 2007
 
 
The viewport idea (what I would call virtual, since your data will be separate) is the most efficient.

>I'm doing this in Windows Forms 2.0, though I think the concept is platform-agnostic.

Your options will be limited by the component you are building on top of if you're not drawing your grid from scratch. Usability of your end result is going to depend on this -- one of the things you have not described is how you want the scrollbar itself to work. I guess like Excel you choose some arbitrary extra size, and then use an arrow to go beyond that. Anyway a grid control might either need virtual support or the ability to independently control the scrollbar to get it just how you want.
Ben Bryant
Monday, February 19, 2007
 
 
This sounds like a typical / common problem, and I would go looking for a control that pretty much already does what I need and buy it.

Are there no controls that provide this functionality?

Aaron
Aaron DC Send private email
Monday, February 19, 2007
 
 
I'd say it doesn't matter which approach you choose. 

In either case, develop a reliable display cell and column construct.  Then the ony difference is in the refresh when someone scrolls. In one case you add a column with data from your source, drop a column, then refresh the display.  In the other, I would recommend just updating the entire table from your source (i.e., do not try to copy data from cell to cell, just pull in your updated date range and repopulate from the beginning), then refresh the display.

If you start with the basic cell and column, then you can always change your mind later about how to refresh the table on a scroll click.  Pick the one that feels easiest to you and if you find later that there is some characteristic of the result you don't like, then you can move to the more difficult solution.
Wayne M.
Tuesday, February 20, 2007
 
 
I've used Syncfusion EssentialGrid for something similar.  You can tell the grid control how many imaginary rows need to be availalbe, so that the scroll bar shows up correctly, and then events are fired every time a particular cell's value needs to be looked up.
Notorius L
Tuesday, February 20, 2007
 
 
A scroll bar is a bad idea for a date control from the point of usability.  How does a user jump across years/months/weeks/ completely arbitrary dates using a scroll bar?

Implement a three or four part scroll bar something like

<  < day-21 >  < month-feb > < year-2007 >  >

The left and right most angle brackets represent arrows that actually do what you now want.  the middle 3 pseudo scroll bars change the day/month/year respectively and change the day/month/year of the first column displayed.
Donald Duck
Tuesday, February 20, 2007
 
 
+1 Donald Duck, (in my earlier suggestion, I was not paying attention to the fact that it is dates you want)
Ben Bryant
Tuesday, February 20, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz