[Blama]

Here is an even shorter sequence of clicks also causing the issue:




Best regards
Blama

[Isomorphic]

Thanks Blama - both issues have been fixed in 15.0, along with an optimization that prevents frequent updates of the ghost-canvas during drags, even when the dates hadn't changed.

Please retest with tomorrow's builds.

[Blama]

Hi Isomorphic,

wow, that's fast!
I also have general feedback (tested in Month-view):

- When you create an event and make it "All day", the next time you create an event, it's also "All day". I'm not sure this is on purpose.
- Single day events don't have validators "Time Start < End" and display with the selected Start time
- Multi day events don't have validators "Date Start < End" and just don't display on "Save Event"
- If you hover events from right to left in month view very quickly, the hover box is displayed too far right IMHO, not where the mouse stopped.



General month view design feedback:
- I like the "google calendar"-design of the All Day events very much. I'd say that it would look better for normal events if they also had a google calendar "chip"-design on hover.
- The "[All Day]" displayed for All Day events is removed on Drag and shows up again after Drop. This would look better if it was there the whole time.
- I'm not sure the dynamic height change of week rows with content is on purpose, but it is really confusing. A fixed height like in google calendar would look better IMHO, but perhaps you have reasons for this.




Best regards
Blama

[Isomorphic]

hi Blama, we've made some changes to address bad behaviors- on your points:

1. the issue of whether a cell-click (up and down in the same cell, even with movement) creates a long event (all day) or a regular event (within a day), is supposed to rely on where you click the mouse - if you click in the layout that houses the long events, it should open the eventDialog and create an All Day event - elsewhere in the cell, it should open the eventEditor and create a regular event. We'll take a look at whether this is a bug with area-detection, all-day detection or with it not resetting the All Day checkbox in the eventEditor

2/3. single and multi day event-dates are now validated as expected

4. hover not close to the mouse - you weren't seeing a link-hover here, but a cell hover, which happens as soon as the mouse enters the new cell and, by default, doesn't move until the hover-value changes - you can now set Calendar.hoverMoveWithMouse to true, and it will propagate to the individual CalendarViews, updating the hover more often and moving it with the mouse. We'll switch this on by default. If you wanted to test the idea, you can set hoverMoveWithMouse to true on monthViewProperties in your current build.

Fixes mentioned above are in the queue and will be in tomorrow's builds.

For your second section:

1. We already have the capability to simply show all events as "longEvents" in the monthView, that is, as canvases rather than links. We'll likely add a property to allow that, and styling can be made to look similar to Google's offering, but we won't go much deeper in that redesign unless we have parties interested in improving that aspect of the widget.

2. [All Day] disappearing from the ghost-canvas during drag is a bug - we'll fix it, likely for tomorrow's builds

3. on the dynamic height of the longEventsLayouts - by default, those layouts have a short default height, 10px, just to allow somewhere to drag-create long-events - when you start a drag, we create a ghost-canvas which is taller than that default short layout height, so we resize the layouts interactively in order to display the ghost-canvas without clipping. We already have a change locally to have longEventsLayouts have a minimum height of one longEvent-height, rather than 10px, which will prevent the runtime resizing you see. This should be in tomorrow's builds as well.

[Blama]

Hi Isomorphic,

thanks, I'll wait for a new build and retest.
To clarify, with 1) (new events after the 1st are always All-day) I meant in the Month-view. The logic of where the click is decides the type works as you say in Day and Week-view. In Week-view even for multi day events.

And also for 3) dynamic height of the longEventsLayouts I was taking about the Month-view (like in the video in #18). The current size increase in Day- and Week-View makes sense to me and also looks good.
If you also were taking about Month-View: Is there a difference between Normal and All-Day events in the Week-view, apart from the design? I don't think there needs to be w.r.t. to placing. Here in google calendar the normal and All-day events are being treated equally and placed next to each other.



Best regards
Blama

[Isomorphic]

hi Blama,

All the changes made to 15.0 to date are now available in today's builds of 13.1+, along with various other fixes applied over the last few days.

For your reference, long-events are displayed in a recordComponent that sits above cells - in the MonthView, regular events are displayed as links in the cell-content, below the recordComponent, so they can't, right now, be mixed with longEvents and aligned in the way you showed, with a long-event next to a regular event.

However, we do still have some other tweaks to make here.

Note that for resizing due to the ghost-canvas being displayed in a layout, we've made two enhancements here, which will be in tomorrow's builds.

1. in the case of the existing mode, where a full-height longEvent ghost is shown, the default height of longEventLayouts now matches longEventHeight, so rows will no longer resize during drag-create unless they are already full of regular events. However, this mode has an issue, in that you can't see the ghost-canvas particularly well, because it renders on top of any existing events.

2. a new mode, the default, shows the ghost-event in the 10px area that is always present in longEventsLayouts - the canvas is rendered at 10px (or whatever longEventLayoutSpace is set to) and does not show text - but it is guaranteed to always be visible, whether there are existing events in the layout or not. By default, this space is visible below existing events in each layout, and you can change it to appear above them via longEventDragVAlign.

[Blama]

Hi Isomorphic,

I retested with SNAPSHOT_v15.0d_2026-03-03.
Thanks for the explanation of All-Day(=recordComponent) and Normal(=Cell content) events. That then makes sense.
Would it be possible to have fixed week heights in Month-View, even if this is wasting screen real estate? This still might make sense if the Calendar is tall enough. This content moving seems disturbing to the eye and somehow wrong.

The new ghost Canvas are really nice.

Other than that, I found an issue with month switching and All-day event placing in month view:


Here in week and month view "clicks" for Drag-And-Drop are not cancelled, if you move the start date to a day where the event was already happening.
Create an event 24th/25th. Moving it to 25th/26th shows the event detail box (unexpected), because the click is not cancelled. If you move it back and then move it to 26th/27th, the event detail box is not shown (expected):



Also, there are no validation errors for start > end when you click "Save event" (unexpected). It does work in Non-All-Day mode, where you can see the time portion.



The docs don't seem to have longEventCompactDrag (mentioned in the other thread) and longEventDragVAlign (mentioned in #21).

Best regards
Blama

[Isomorphic]

hi Blama,

We've just committed a bunch of fixes and enhancements that'll hit tomorrow's builds.

On the things you mentioned:

1. the All Day="canvas in a recordComponent " rule now works, with the addition that any drag-created multi-day event (in the layout or the cell) is now also defaulted to All Day - and the popup dialog shows [All Day] in the title, as appropriate

2. you can set calendar.minimumDayHeight to get fixed (min) height rows - make that 200 and you'll get more room

3. drag-moving a multi-day event in the WeekView, so that its start-date is still within the original range of the event (eg, drag a two-day event 1-day to the right) no longer shows the eventEditor on drop

4. validation in the eventEditor is now comprehensive, and re-validation happens when values change and when the allDay or multiDay checkboxes are toggled

5. the docs - the attribute-names changed again, for those that had only been around for a day or so - the old mechanism of showing a full-height longEvent during drag was considered a bug (couldn't see it if there were real events present), and has been removed altogether. The new feature is controlled by:

- longEventLayoutSpace: the (existing) drag-area height
- dragGhostSpaceVAlign: drag-area placement, top/bottom, above/below real events - default top
- dragGhostHeight: the height of the actual ghost canvas, default 4px
- dragGhostVAlign: the alignment of the ghost-canvas in the drag-area space, default center

There's a 15.0 sample you can play with, here.

6. also fixed a tricky MonthView bug where drag-creating a multi-day event by starting the drag in the cell body, rather than the longEventsLayout, would show the ghost in the correct cell initially but wouldn't expand if dragged into the cell immediately to its right - any other cell worked fine - similar issue to #3

[Blama]

Hi Isomorphic,

thanks, I will retest with a new build. Regarding the new sample: That's great, makes testing easier.

One thing I noticed is that the events-end is 00:00, while I'd expect 23:59. The way it is right now, the two events seem to be 3 or 4 days long, but don't show up in the last day in Day-view. I assume this is just a sample setup error.

Perhaps you can add All-Day, Multi-Day and All-Day-Multi-Day events by default, so that it's easier to test.

Best regards
Blama

[Blama]

Hi Isomorphic,

I retested here with SNAPSHOT_v15.0d_2026-03-05.

1) I can see that the [All day] naming works now

2) I can see that Calendar.minimumDayHeight works, but not as expected, it also affects the row with the day-numbers (in the sample height: 1000 for the Layout and minimumDayHeight: 400 for the Calendar).


3) I can see the click is now cancelled as expected, but saw this behaviour somewhere else as well today, but could not reproduce yet.
Also, drag-create of multi day events over existing events does not work, only in the ghost area or "at the other side" of the existing event. See when exactly the Ghost Canvas size changes in the video. I assume this is related, and the over is cancelled while on over existing events.


4) I can see revalidation happens.

5) Thanks, the sample is great.

6) I might have found a similar issue in week view. Will post in a new comment here, if not related.


Best regards
Blama

[Blama]

Hi Isomorphic,

continuing the previous post, this is what I mean:


Steps to reproduce:

• Start sample
• Clear existing events
• Drag create events like in the video

Issues:

• 1st event: Thu-Fri is fine
• 2nd event is Fri only, should also be Thu-Fri
• 3rd event is Thu-Fri (OK), but the Ghost Canvas shows Thu-Sat.

Best regards
Blama

[Blama]

Hi Isomorphic,

continuing and probably related to your #23.6:

In Month-View All-Day-events created in the Cell section eventually are 12:00-13:00 only.

In this video it is happening immediately after Sample start, Switch to Month View, but sometimes it takes a few event creation attempts to trigger.


Also, events normal events created in the Month View Cell area show an end time of 23:59 for a split second (visible in the video). This is unexpected.


Best regards
Blama

[Blama]

Hi Isomorphic,

also some minor feedback on the "New Event"-Detail window:

1) Different to the Mini-"New Event" window, this one does not close on "Esc"-key. From testing it, it would be better if both closed on "Esc"-key.

2) The height setting for the components can probably be optimized. If you have a very high calendar (for many events in month view), the layout for this one is not nice, too much space between To/From and OK/Cancel buttons. Please test with height: 1000 for the VLayout of this sample.
Probably the Window should not use 100% of the Calendar size.

3) Please enable "Multi day" and then toggle "All day" a few times. You will see that the name of the start field jumps between "Date" and "From", while the "End" name stays constant. I think it should always be "From" for "Multi Day"-Events.

4) There might be an Alinment issue with validation error for All-Day-Multi-Day events. Not sure this is expected or an issue:



That's it for now. It's really cool to see this coming along, as it is looking great and will be a fabulous addition!

Best regards
Blama

[Isomorphic]

Thanks Blama - we'll take a look at these various issues and update here when we've fixed them.

[Isomorphic]

hi Blama,

We've made a bunch of fixes and improvements - here's how they relate to your reports:

- 24.0 - we've updated the sample to include 4 events: sub-day, all-day, multi-day and all-day + multi-day.
    Also made value-changes in the formItems redraw the Calendar right away

- 25.2 - we don't see this effect by setting minimumDayHeight: 400, in 13.1 or 15.0, or in Chrome/Firefox. The
  header remains at 30px (in Spacious), and the body gets the rest of the height. However:
  - we'd be interested to know your OS/Browser setup if you still see this issue in the Showcase
      - 13.1 vs 15.0 - the latter uses an optimized grid-rendering mode by default (LG.divGrid/centralStyling)
  - we've shored up this logic and made some changes anyway
      - Calendar.monthDayHeaderHeight (20px) and monthDayBodyHeight (null) now let you control the sizes
        separately, if you wish
      - fixes to tricky space-sharing logic now mean that you'll rarely see rows resize as you drag/drop events
        into them, as you noted earlier in the thread
      - cell-content will now shrink when the longEventsLayout increases in height, with a min of one
        link-height for existing link-events (or "More...")

- 25.3 - this is fixed

- 26.1 - we're also not seeing this in 13.1 or 15.0, Chrome/FF - the ghost is always well-placed and properly
  sized, and the popup always shows the right range - but note that there have been almost daily recent changes
  in this code, and lots of new autotests now exercise it - so perhaps just retest this one and let us know

- 27.1 and .2 - these are fixed

- 28.1 and .3 - these are fixed
- 28.2 and .4 - we're not going to make any changes for these cosmetic issues for the moment - if we do, it'll
  likely be in 15.0 only

Most of these fixes are already in today's 15.0, and they'll all be in 13.1+ in tomorrow's builds, dated March 9 and later.