Timeline error when trying to use "quarter of hour" granularity.

[mathias]

This pronlrm is something you can easily see by going in to your own showcase, the "timeline resolution" example.

I want to be able to show 24hrs, with 15 minutes granularity. The user should be able to drag the events to, for example 06.45 - 12.15.

code to set up the granularity:

HeaderLevel hour = new HeaderLevel(TimeUnit.HOUR);
hour.setHeaderWidth(50);
HeaderLevel minute = new HeaderLevel(TimeUnit.MINUTE);
minute.setHeaderWidth(50);
HeaderLevel[] headerLevels = new HeaderLevel[]{hour, minute};    

setResolution(headerLevels, TimeUnit.HOUR, 24, 15);

There are two issues:

1. In your showcase you can only select whole hours in the timeline. You can open and edit, but the timeline only display full hours, even if you hover and see the actual time.

2. The point above seems like a 6.1 thing, because it *kind* of works for me in 6.0 with the above code, only that the minimum length of the event is one hour. I can drag to for example 12.15 - 14.45, but if i drag to 12, it moves so that the event is one hour.


I would argue that the expectancy is for the calendar to work as described in the API, and how you'd expect as an end user. That is, if you define the granularity as in my code above, you should be able to drag and drop with quarter granularity, and the timeline should display the correct values.

[mathias]

We have looked into this a bit more, and we believe the issue lies with "setEventSnapGap".

If we understand it correctly, in the showcase you set it to 60, which causes all events to snap, *and display* to one hour, even if you set it to less than that manually (for example by clicking edit in the showcase).

We do not set that, and from what we experience, it doesn't work 100% when not set and switching between resolutions.

According to the API docs, we expected it to basically have the snapgap being whatever the column was. However it behaves inconsistently.

We have tested creating an event that is 15 minutes. Sometimes, it snaps to the full hour, but after going to "week resolution" then back to quarter of hour resolution, the event suddenly is displayed as 30 minutes long (i.e. spanning 2 columns), even though the actual event is only 15 minutes. The hover always shows the correct time.

We could not understand why the event would display as 30 mins, and not 15 minutes or one hour., your api docs mention "If unset (the default), all views will snap to each cell boundary; 30 minutes in a default vertical view, or one column in a default Timeline".

Not sure how to proceed. Right now, we have set the snapGap to 15 minutes, which at least makes it behave consistently, but since we cannot have different gaps in different resolutions, this causes the snapgap to be 15 minutes even in week view, which is not optimal.

[Isomorphic]

We're not seeing any misbehavior in the Timeline Resolution sample.

An event will be drawn at the nearest snap-gaps to it's actual dates, by design.

If we change to the 12 hours/15 mins resolution and add a 15 minute event, it shows in one column.

If we change to the 1 day/hours sample, it still fills 1 column, even tho the column represent 1 hour (because the default snapGap is one column wide).

If we change back to 12 hours/15 minutes resolution, the event appears back in a single 15-minute column, as it should.

Note that you can set eventSnapGap to 1 if you like, and that will choose the smallest gap that can be represented in the current resolution.

Or, you can choose a snapGap yourself when you change resolution.

[mathias]

We got this in the build from May. After we updated to december 2:nd, we do not see the behavior either.

[Isomorphic]

We just tested this again, in the 6.0 build from December 2, online.

We see no issues - either making no eventSnapGap changes, or calling setEventSnapGap(1), works as we described previously, and this is true in latest 6.1 and 12.0 as well.

Let us know if you find a way we can test, either in an online sample or with a standalone testcase, to replicate a misbehavior.

[mathias]

Hi,

i actually wrote above: "after we upgraded to december 2:nd, we do not see the behavior". So we are in agreement!

[Isomorphic]

Ah, apologies, our misunderstanding.