moonwalking timeline

I have a timeline in my application that starts to behave weird when I use ‘setVisibleDateRange’:

  • I do ‘setVisibleDateRange’, for example with a range ‘10 sept 2004’ upto ‘30 august 2010’ when the user clicks somewhere
  • I have registered a dateRangeChanged event listener
  • this listener receives a notification, but the dates are slightly different: the start date is ‘08 sept 2004’, end date is ‘2 sept 2010’
  • I record this date (I use it to query a subset of my database)
  • next time the suer clicks I do ‘setVisibleDateRange’ with these values, the event listener receives again a notification with slightly different start and end, etc.

The end result is that, when you click a number of times, the timeline slides backwards, and the timewindow extends slightly.

Is there a way to avoid this effect? Since I use the timeline to select a portion of my database it’s important that the timeline itself doesn’t change the values of the timerange I set myself. I also don’t wantto bypass the 'dataRangeChanged event listener, since there are other ways to change the time range (dragging the timeline for example).

Are you using the latest version of the add-on? I recall a bug related to the time window moving backwards was fixed recently, but I am not certain if there has been a release since then and I don’t know if it was the same problem you are using.

This does sound kind of like ticket
#8215
to me, but I am not certain.

Another possibility without looking at the implementation is that the DateRangeListener is recieving the rendering date range instead of what actually is visible in the component. Since the rendering date range is always somewhat bigger than the actual visible date range then it could cause that kind of drifting your are describing. This would obviously be a bug which should be fixed.

Please try the new version (currently 1.2.4) with the fix for
#8215
and if it doesn’t fix the issue then please create a ticket in the vaadin trac.

I’m using timeline 1.2.4. I created a new ticket (
ticket 8545
)

Tx for all the responses,
Kim