[Isomorphic]

hi Blama,

As it happens, we'd already fixed up the hover-issues in the ghost-area - the hover only showed once on layout mouse-enter, then was hidden as the mouse changed dates within the layout; then moving the mouse out of the ghost-area and back into it would show the hover. Anyway, and as you noted, there's no point in displaying a date-hover over the longEventsLayout itself in any of the views, really - the actual date is always right there by the mouse anyway. That said, if showCellHovers is true in monthView, it should behave the same way over the ghost-area as it does over the rest of the cell.

We'll do a quick hover audit throughout and let you know what changes we make.

[Blama]

Hi Isomorphic,

I can see that the remaining bugs in this thread are fixed as well (SNAPSHOT_v15.0d_2026-04-10)!

I noticed that the hover for All-Day events does not show the event description in Day-View and Week-View (unexpected), while this happens for sub-day events.
It does not show the description at all in the hover for Month-View (unexpected).

Also, the Ghost Space in all three modes shows the date as hover. I'm not sure this is on purpose, as it does not really help.

Best regards
Blama

[Isomorphic]

Thanks Blama - that alignment issue was a 15.0-only and Firefox-only regression, introduced on April 6 by an unrelated change to the ListGrid.divGrid mechanism.

It's been fixed for today's builds.

[Blama]

Hi Isomorphic,

I can see the exception with SNAPSHOT_v15.0d_2026-04-06 - probably the reason for the issue I saw. Will retest with the next build.

Here a video of the jumping day numbers:



Best regards
Blama

[Isomorphic]

hi Blama,

1. There was indeed a bug when clicking in the last row to move to another month, if the new month had fewer rows - there was a crash logged in the console. We've fixed that just now, for tomorrow's builds.

2. we're not seeing any visual issues with header-row titles moving around in FF149 - perhaps show a video if you can still reproduce.

[Blama]

Hi Isomorphic,

I'm using SNAPSHOT_v15.0d_2026-04-06 now. I can see that #34.3 and #34.4 do no longer happen.
Something else strange seems to be happening though around switching month by clicking a day of the next month in Month-View, but I have to retest.

Also, in Month-View in FF149 (but not Edge146) the day numbers flicker from right-align to left-align on hover.

Best regards
Blama

[Isomorphic]

hi Blama,

We've definitively fixed #34.4, but we still aren't seeing #34.3 - clicking anywhere in the specific dates you mentioned always changes the month. That said, today's fix may have improved whatever you were seeing, since it's in the same flow. It's likely worth a retest with tomorrow's build.

We've also added a "Use DataSource" checkbox to the dragGhostCustomization sample - as requested, it toggles between a DS and inline data. Interestingly, all the recent changes have made calendar re-drawing efficient enough that we had to add an extra event into the DS cacheData, just so you could see something happen on-screen as you switched modes!

Please retest with tomorrow's builds, dated April 4 or later.

[Blama]

Hi Isomorphic

coming back to #34.4: This does work for the cell area, not the All-Day area.
Start the sample (SNAPSHOT_v15.0d_2026-03-26) and go to March 2026 month view. A click on Sat, April 4th will switch the month if you click in the cell area for normal sub-day events, not if you click in the All-Day event area. It should do that in both cases.

Best regards
Blama

[Blama]

Hi Isomorphic,

I retested using SNAPSHOT_v15.0d_2026-03-23 using FF148.

I can see #34.4 is fixed, month switching does happen.
#34.3 is not fixed, I can still create an All-Day event on 2026-05-01 when in Month View for April.

Thanks for the feedback on #36 :)
IMHO it's a lot easier to find minor bugs, than to create an almost bug free framework of this size. So all the kudos back to you!
I could not reproduce the issues in #36 now, so I think they are fixed.

Best regards
Blama

[Isomorphic]

hi Blama,

You are a very determined developer, sir - watching the videos of you trying to hit these issues with repeated clicks is mesmerizing! :)

We've made some changes:

#34.3/4 are fixed

# 36.1/2 are fixed

On post #39 - we haven't made any changes here just yet. The problem with making events span from midnight to 23:59 is that they'll fill the entire calendar in vertical views. They won't be considered all-day events (in terms of them being displayed as horizontal long-events), even if they span 00:00 to 23:59. The current behavior of retaining the existing start/end times seems better - if you click to create a sub-day event, it'll have time noon-1pm, check the All Day checkbox and save, then you click the event to re-open it, un-check the All Day checkbox and save, it'll have the times it was created with. If you change the times to 00:00 and 23:59, those times will be retained in the same way. On the question about dates vs datetimes - we'll have to have a bit of a look and get back to you on that.

We haven't added a new databound sample just yet, but one should be added in time for tomorrow's builds - probably more than one, actually.

[Blama]

Hi Isomorphic,

I understand the behaviour in the editor and agree this is the best thing to do.
For the "Save event" click and an All-Day event I'd try to persist the time portion as follows:
Start: 00:00:00 (or whatever you have to do because of the timezone)
End: 23:59:59 (or whatever you have to do because of the timezone)

But I agree this isn't easy in general, also for All-Day events. I'd assume the second portion should always be 00 for start and 59 for end. This way the data is more easy to use in other systems.

More general:
I assume you will always want to use DataSourceField.fieldType datetime objects and columns, even for All-Day events? Or are just date fields also OK for all-day events? Would mean more columns in the Database I assume. I can see how this is not easy :)

Best regards
Blama

[Isomorphic]

hi Blama,

We'll take a look at the reports in post #36.

No, setting the allDay flag does not null out the time-portion (we assume you mean set it to 12-noon, so it's a logical-date) - if allDay is set, it doesn't matter what the time-portion is, it's ignored, but leaving it there means that if you uncheck the All Day checkbox, you have sensible time values in the editors. This seems like good behavior - if you tick the All Day box, the times disappear, if you untick it again, the times are still there. We understand that you're saying a successful Save should clear the time-portions, but since we'd have to set the times to *something*, they can't be null, it seems sensible to keep the times that were already there.

But we're happy to reconsider if you have specific thoughts.

We'll add a DS-backed sample anyway.

[Blama]

Hi Isomorphic,

regarding #35.1/2:
What I meant is not that the time is 12 noon to 1pm, which I would expect. It is 1:00 till 2:59, like in the sample code. So setting the All-Day flag does not seem to null out the time portion. IMHO this should happen after a click on OK. Otherwise it will be confusing in persisted data.

Because of this I think a sample with persisted data would be good. Perhaps even with a Validator in the DataSource definition to see the effect of validation errors.

Best regards
Blama

[Blama]

Hi Isomorphic,

more issues in Mouse interaction:

1. Sometimes you can click-create All-Day events on Sundays in Month View (unexpected). Does not always work, so must be area related or minimal Drag-And-Drop? FF 148 and Edge 146, v13.1p_2026-03-13 and SNAPSHOT_v15.0d_2026-03-18. In Edge 146 more it seems.
   
2. Sometimes you can click-create All-Day events on Sundays in Month View by clicking the All-Day event area at the top of Sunday (unexpected). This only works for one event and seems to happen more in the lower area of the Ghost Space.
   

Best regards
Blama

[Isomorphic]

hi Blama,

1. No, that's not a bug. An allDay event is just a regular event (including times) with its allDay flag set, and the default length of a new event (they were always sub-day until recently) has always been an hour from 12 noon to 1pm.
2. See the docs for Calendar.allDayField - we could add a databound example as well, there shouldn't be any difference (and autotests exercise both modes)
3. we'll take a look at this shortly
4. and this one