`loadDateRange` triggers with `change` equals to true when dragging over event

[chuckn0rris]

Forum post

https://bryntum.com/products/scheduler/examples/infinite-scroll/

In console

scheduler.eventStore.on({
  loadDateRange: ({ new : { startDate, endDate }, changed }) => {
    if(changed) {
      console.log('loadDateRange triggered?!');
    }
  }
});

drag and event and hover over another event. See loadDateRange triggered with change = true, but it shouldn't be true

[ExtAnimal]

Several issues here.

The first one is that that new code is completely invalid. It gathers events for the resource over which which mouse pointer happen to be.

The underlying issue is in EventDrag#getProductDragContext

The way it resolves targetEventRecord in EventDrag#resolveEventRecord is different from the way EventDrag#resolveResource resolves the target resource.

The target resource is ascertained from the position of the center of the dragged event element.

The target event is ascertained from the target element of the mousemove event which, if you grab the event right at the bottom may be in a [b]whole different row[/b]

The code added which does this in https://github.com/bryntum/bryntum-suite/pull/9848 should be reverted and the resolution of "over" records i getProductDragContext should be made consistent. It can still get differing values depending on where the event bar was grabbed, and the layout of the events. In the following scenario, the event bar was grabbed at the top, and you cab see that it still gets different values:

The targetEventRecord must be ascertained from the center point of the Rectangle.from(context.element, null, true).center rectangle, NOT from the target the mouse pointer happens to be over.

client.getEventRecord(DomHelper.elementFromPoint(centerPoint.x, centerPoint.y))

Tangentially related is the need for a silent property to the GetEventsMixin#getEvents which suppresses the triggering of the loadDateRange event.