Hello!
I am encountering a problem with event names when switching days in the scheduler.
Sometimes the event name which starts on the previous day or continues to the next day does not have the event name or the name is partially visible. My code is using "shiftPrevious" or "shiftNext" functions to switch between days.
Could you please advise me on how to fix this?
Hi natalija,
How can we reproduce that? Do you see this problem in our online examples?
I tried this demo
https://bryntum.com/products/scheduler/examples/bigdataset/
In console I called
scheduler.shiftNext()
// and
scheduler.shiftPrevious()
in different order and I don't see that problem. Maybe some specific configuration required?
Please try to reproduce it with our demos and provide steps to reproduce.
If required, apply minimal changes to our example and share with us.
Or zip and attach a test case that we could run and debug.
I was able to reproduce something similar on the demo: https://www.bryntum.com/products/scheduler/examples/recurringtimeranges/
It is not completely the same scenario but the problem looks similar.
When a new event is created which starts outside the visible date and continues in the visible date, the event name doesn't show up after saving. Only after clicking to create another new event the name shows up.
Seems like position:sticky doesn't activate until a scroll happens. I will experiment if there's anything which we can do to "wake up" the DOM and get it to stick the event inner element correctly.
This is the incantation:
e = scheduler.getEventElement(newEvent).firstChild;
e.style.position='static';requestAnimationFrame(() => e.style.position='');That kicks stickiness into life. We need some equivalent in the event rendering pipeline.
Could you please show more explicitly using the demo where this code piece should be included? And can you explain what is meant by newEvent?
newEvent is just created event. It may be added into https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/view/SchedulerProBase#event-afterTaskEdit listener.
But seems like this won't fix the case from your original post. We need to apply fix internally anyway, but you can use this code and fix it for certain cases like the one you mentioned above.