[BUG] Packed events overlap when fillTicks is true and times don't overlap
Posted: Sun Jun 26, 2022 5:42 pm
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.
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.
Re: [BUG] Packed events sometimes overlap
Posted: Mon Jun 27, 2022 9:33 am
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.
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
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.
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
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...
Kind regards,
Laurens
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
Posted: Wed Jun 29, 2022 10:34 pm
by lxxrxns
Thanks a lot! Glad I found a bug <:-)
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
Posted: Wed Jan 18, 2023 4:31 pm
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
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
Posted: Wed Jan 18, 2023 4:32 pm
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,
},
Re: [BUG] Packed events overlap when fillTicks is true and times don't overlap
Posted: Wed Jan 18, 2023 5:03 pm
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