[ANGULAR] ScrollToDate with block: center and viewportCenterDate not the same

[Exigo]

Hey

We have an issue where we do some tick management and want to keep the original center date to set to again. But when we try to scroll to it, it jumps ahead a little bit. Am i using the function wrong or is the viewportCenterDate something else?

I've added the following code to the example: https://bryntum.com/products/schedulerpro/examples-scheduler/scrollto/

    {
        button: 'button',
        text: 'center',
        onAction: () => {
            scheduler.scrollToDate(scheduler.viewportCenterDate, {block: 'center'})
        }
    }
        

2024-12-13_12h30_42.mp4

(1.16 MiB) Downloaded 38 times

[marcio]

Hey Exigo,

Thanks for reaching out and for the detailed report.

That looks like wrong behavior, here's a ticket to track the fix https://github.com/bryntum/support/issues/10486.

[Animal]

scrollToDate says "Scrolls the timeline "tick" encapsulating the passed Date into view according to the passed options"

So in your video, it gets the viewport center date. Which, as we know, a Javascript Date is in fact a timestamp, so it's a time, and rounds that to a whole date, and then scrolls the 100 pixel wide "block" encapsulating that date to as close as possible to the center.

And then your button does That again. So probably gets that date just after 12:00:00.000 (remember, at that scale, every single pixel is 14.4 minutes), rounds that to a new whole date and scrolls that block into view.

Maybe this might be better?

scheduler.scrollToDate(DateHelper.floor(scheduler.viewportCenterDate), {block: 'center'})

[Exigo]

Hey Animal,

Same result. I'll see if I can't find a solution.

Cheers
Andreas @ Exigo

[Animal]

I cannot see the requirement.

Scroll the center date to the center????.

[Exigo]

Requirement?

I'm not sure i understand? The issue is right now there is no way to save the old center date and scroll to that one again without viewer jumping a bit in time. You can see the video in the github issue where the bug happens.

Cheers
Andreas @ Exigo

[alex.l]

Try to save and position by start and not by middle to prevent that behaviour.

scheduler.scrollToDate(scheduler.visibleDateRange.startDate)

https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/view/SchedulerPro#property-visibleDateRange

[Animal]

Set this property: https://bryntum.com/products/scheduler/docs/api/Scheduler/view/Scheduler#property-visibleDate

[Exigo]

Hey Alex,

The issue is that start date is that i don't want the start date, since in my case i'm changing the amount of ticks, so setting the startdate would also cause a "jump".

Hey Animal,

same issue. Tried the example with:

onAction: () => {
       scheduler.visibleDate = {
      date: scheduler.viewportCenterDate,
      block: 'center'
    }
  }

[Animal]

The inaccuracies introduced when converting pixels to a precise date and vice versa means that you can never scroll to a real Date object down to milliseconds.

Try this incantation to round the date being requested to what the current viewPreset renders in its leaf ticks:

scheduler.visibleDate = {
      date: DateHelper.round(scheduler.viewportCenterDate, {
          unit : scheduler.viewPreset.leafUnit,
          magnitude : scheduler.viewPreset.leafIncrement
      }),
      block: 'center'
    }