visual glitch using Calendar.allowLongEvents

[claudiobosticco]

SmartClient Version: v13.1p_2026-02-03/AllModules Development Only (built 2026-02-03)

I previously sent this report by email, but I am reposting it here now, given that allowLongEvents is now documented.

I’m writing to report a mostly visual issue that occurs in the Calendar when using allowLongEvents: true.
I’ve uploaded a video to illustrate the problem:
https://www.youtube.com/watch?v=teNz6UN-rFs

It’s the showcase but I see a similar behavior in my own application.

To reproduce it, you can use the customCalendar sample with allowLongEvents: true added.
In the Month view, when clicking on a day to create an event, there is the visible effect, shown in the video, where existing events briefly jump upward and then return to their previous position.
A scrollbar also appears because the Calendar height increases by a few pixels.

In addition, a “ghost” longEventsLayout becomes visible on a day different from the one that was clicked.

[Isomorphic]

Thanks Claudio - we did receive the report and it's with the engineer.

The problem is down to how we show regular events in the monthView, as content in the cell - current code does a full setData() on the grid which hides and re-shows the long-events, when you add a new event - we've made a couple of tweaks and improved things a bit, but it isn't fully addressed as yet.

We'll update here shortly.

[Isomorphic]

hi Claudio, and apologies for the long delay in getting these fixes into 13.1 - they're available in today's builds.

You should no longer find any issues with flickering or misplaced longEvents - there is a new attribute, calendar.fixedMonths; if you set that to true, it'll always shows 6 weeks in the monthView and never need to call setData(). When it's false, the default, setData() only runs potentially once when the month changes, if the week-count is different in the new month. Otherwise, all updates, refreshes, redraws, drag-behaviors, etc, affect the data directly and refresh rows.

Many other fixes and improvements have been made as a result of the other thread that yourself and Blama contributed to.

As noted in that thread, as of tomorrow's builds, you will also find attributes longEventMinimalDragHeight (default true) which shows an always-visible ghost-canvas of a shorter height during drags, and longEventDragVAlign (top/bottom) which indicates where that compact ghost-event should render, relative to other longEvents in the layout. These are new and not the best names in the world, so we might rename them before tomorrow's builds - we'll let you know if we do.

Please let us know if you see any other issues.

[Isomorphic]

Note a couple of changes - Calendar.longEventMinimalDragHeight has been renamed, as we said it might be, to longEventCompactDrag, and longEventDragVAlign has been set to "top" by default, such that the longEvent drag-area (longEventLayoutSpace) is always at the top of every longEventsLayout, above any real longEvents.

When you drag-create or drag-move a multi-week event, the ghost canvas is now always visible during the drag (not overlaying any real events) and never has any complications with resizing, because it sits in the always-present longEventLayoutSpace.

If you want to return to the previous mechanism, set longEventCompactDrag to false.