[claudiobosticco]

Thanks Claudio - we'd actually already fixed this one and you'll find the fix in tomorrow's builds. You'll also find many recent 13.1 Calendar bug-fixes, in which we include adding working rangeCriteria, have been ported to 13.0 in tomorrow's builds.

Thank you very much.

By the way, I just noticed that on iOS I've got this error in my application with build "SNAPSHOT_v13.1d_2024-09-10/Enterprise Deployment" (doesn't happen with "SNAPSHOT_v13.1d_2024-09-09/Enterprise Deployment")

[Warning] *18:07:16.193:TMR7:WARN:Log:RangeError: Maximum call stack size exceeded. (ISC_Core.js, line 33293)
Stack from error.stack:
stringify@[native code]
_serialize@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:70956:39
_serializeObject@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71173:32
_serialize@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71034:33
_serializeArray@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71061:28
_serialize@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71021:36
_serializeObject@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71173:32
_serialize@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:71034:33
encode@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:70687:33
encode@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:70462:51
echoFull@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:30966:31
isc_echoFull@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Core.js:2595:70
_refreshData@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4350:45
refreshEvents@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4159:30
_refreshData@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4351:47
refreshEvents@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4159:30
_refreshData@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4351:47
refreshEvents@https://localhost:8443/Jat/isomorphic/system/modules-debug/ISC_Calendar.js:4159:30

this error happens in a piece of code where I do calendar.fetchData() and then animateShow() on the layout containing the calendar. Actually doing the fetch in the animateShow callback fixes the problem, but I don't think it's normal to have that error.

[Isomorphic]

Thanks for the reports guys - the issue is that floating-scrollbars in Firefox do not consume mouse events, so the calendar body was picking them up and was indeed performing drag-selection to create a new event.

Please retest with tomorrow's builds, dated September 10 or later.

[claudiobosticco]

Hi Blama , now I see it, also while using the trackpad, it seems it's selecting cells while scrolling.

[Blama]

Hi all,

ah, for it to happen you need to select an enabled day in day view and set disableWeekends:false in week view.
Tested here.

Best regards
Blama

[claudiobosticco]

Hello, I didn't manage to reproduce Blama 's bug with FF and MacOS, but found another one :)

This also happens with a grid: if I drag a scrollbar down and outside the browser window while holding the mouse button down, and then return to the browser window, always with mouse down, I see the scrollbar moving, but the scrollable area remains still.

[Blama]

Hi Isomorphic,

I can see both issues (fetch size, Date/DateTime for quick add) are fixed using SNAPSHOT_v13.1d_2024-09-10.
I noticed a design issue in day/week view now though, when dragging the vertical scrollbars (tested in FF129), where there is a growing gray block in the rightmost column.

Best regards
Blama

[Isomorphic]

Thanks Claudio - we'd actually already fixed this one and you'll find the fix in tomorrow's builds. You'll also find many recent 13.1 Calendar bug-fixes, in which we include adding working rangeCriteria, have been ported to 13.0 in tomorrow's builds.

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-09-10/AllModules Development Only (built 2024-09-10)

Hello, the refreshData/invalidateCache methods seems to work only for day/week views, I don't see fetches to occur when in the month view.
You can test it in the showcase (databoundCalendar sample):

// using a client-only dataSource so that test data is always relative to the current date
isc.DataSource.create({
    ID: "eventDS",
    fields: [
        {name: "eventId", primaryKey: true, type: "sequence"},
        {name: "name"},
        {name: "description"},
        {name: "startDate", type: "datetime"},
        {name: "endDate", type: "datetime"}
    ],
    clientOnly: true,
    testData: eventData

});
isc.IButton.create({
    ID: "refreshButton",
    snapTo: "T",
    title: "Refresh",
    click: "eventCalendar.refreshData()"
})
isc.Calendar.create({
    ID: "eventCalendar",
    children: [refreshButton],
    startDate: eventData.getDataStartDate(),
    dataSource: eventDS, autoFetchData: true
});
refreshButton.bringToFront()

[Isomorphic]

hi Blama - we've fixed both of the issues you mentioned.

New events in monthView will now have datetime start and end dates as expected and, for the range of the monthView, you were actually seeing a fixed 40-day range, applied by logic that had been in place for many years.

Please retest with tomorrow's builds, dated September 9, or a later one.

[Isomorphic]

hi Claudio - no news on the "[N/A]" issue as yet, but we've improved Calendar.invalidateCache() and refreshData() so that both should now refresh the selected view fully, including re-fetching the data in its current range.

hi Blama - thanks for the reports - we're taking a look and will update shortly

[Blama]

Hi Isomorphic,

I noticed that the fetches in Month view are always 6 weeks, even if you only display 5 weeks, like in June 2021. A 6 weeks-fetch make sense for e.g. May 2021.
Not really a problem, but perhaps something you want to optimize.

Best regards
Blama

[Blama]

Hi Isomorphic,

using SNAPSHOT_v13.1d_2024-09-06 I can see that the fetch is now using DateTime for startDate and endDate.

But if you add an event, it's still a Date for startDate and a DateTime for endDate if you quick-add an event by "Click date" -> "Enter Name" -> "Click save".
I'd expect a DateTime for startDate here as well. And it is a DateTime for both, if you click "Edit details" and then "Save".
So only the "small" editor creates Dates instead of DateTimes for startDate.

Best regards
Blama

[Isomorphic]

hi Claudio - we agree there should be standard support for invalidating and refreshing Calendar data. We'll be reviewing the current API and will let you know when we've made something public.

The [N/A] content in the Raw Response tab is indeed not Calendar-specific - we'll update here once it's been addressed.

[claudiobosticco]

FYI I've already tried calendar.data.invalidateCache() and has no effect.

otherwise, my tests are positive so far (there's only that [N/A] in the Raw Response tab which I don't think it's related to the Calendar)

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-09-02/Enterprise Deployment (built 2024-09-02)

Hello, while I'm testing it, a question comes to mind: could the Calendar also support refreshData() and/or invalidateCache() methods?