Our pure JavaScript Scheduler component


Post by lxxrxns »

I've been having an issue with the "pack" event layout. Sometimes (but not always), most often when you have an event in the morning and an event in the afternoon on the same day, the events will overlap in stead of pack.

See the following example where TTE and TEE are two activities. TTE is always in the morning, while TEE is always in the afternoon. Yet when I assign both activities to the same resource, they overlap when I set the event layout to "pack". When I switch back to "stack", they of course both become visible again.

Image

Do you have any idea what may cause this? Is it a known bug? And what can I do to fix it?

UPDATE: I figured out the cause: it's because I use fillTicks with events that don't overlap timewise. Thus, the events are shown next to eachother (left and right), but because fillTicks is used, they are both expanded over the entire tick, thus they are not shown as two smaller rows...

Would it be possible to change the eventEndTime on render, but not have this changed in the database? Because if we can render all events as an endTime of 23:59, the problem would be fixed.

Last edited by lxxrxns on Mon Jun 27, 2022 10:12 am, edited 2 times in total.

Post by lxxrxns »

Update: after some further testing, it seems this only happens when the two events do NOT have overlapping times.

I.e. when I place two activities that both last from 08:00 till 17:00, they are 'packed' correctly.
However, when one of them lasts from 08:00 till 13:00, and the other one from 13:30 till 17:00, they are shown on top of eachother in the scheduler.

This may be related to me using the option that all events are snapped to the entire day (fillTicks = true).

Still, I think it should be considered a bug? I.e. when we use fillTicks, and there are multiple events in a day that don't have overlapping start/end times, these events are shown on top of eachother in stead of 'packed' in the 'pack' view.

As a work-around, I will now change the end times of all activities to 17:00 (even the ones that are normally only in the morning), so that at least they aren't shown on top of eachother.


Post by lxxrxns »

Reproduced in example: https://bryntum.com/examples/examples-scheduler/layouts/

Add:

fillTicks         : true,

Then create two events for the same resource, in the same tick, one (for example) with start time 11:05 AM and end time 11:10 AM, and one with start time 11:15 AM and end time 11:20 AM.
You will see that one event now disappears behind the other.


Post by marcio »

Hey,

To solve that, you need to set the allowOverlap config to false https://www.bryntum.com/docs/scheduler-pro/api/Scheduler/view/SchedulerBase#config-allowOverlap

Best regards,
Márcio


Post by lxxrxns »

marcio wrote: Mon Jun 27, 2022 9:45 pm

To solve that, you need to set the allowOverlap config to false https://www.bryntum.com/docs/scheduler-pro/api/Scheduler/view/SchedulerBase#config-allowOverlap

Hi Marcio,

I added allowOverlap : false to the example ( https://bryntum.com/examples/scheduler/layouts/ ) but it doesn't work. I'm using Scheduler (not Pro), but I see that the same function is mentioned in the Scheduler docs, so I'm not sure why it's not working...

Image

Kind regards,

Laurens


Post by marcio »

Best regards,
Márcio


Post by lxxrxns »

Thanks a lot! Glad I found a bug <:-)


Post by thomasb »

I had the same issue. When I changed the value of the property headerHeight from 'auto' to a specific number, for example headerHeight: 30 it's working :-)


Post by thomasb »

the headerHeight in the nested Events properties:

nestedEvents: {
			// Stack nested events initially (can be changed from the toolbar)
			eventLayout: 'pack',
			// Grow nested events a bit, compared to the default which is 30
			eventHeight: 30,
			// Reserve more space above the nested events container
			headerHeight: 30,

	},

Post by lxxrxns »

OK I did something way more complicated to work around this issue xD. I curently have all events with an endDate of 23:59:59 (so that events always overlap) and an additional REALendTime field that holds the actual end time. But hey, it's working :)


Post Reply