Calendar is not showing the Month-Year, when its loaded

[stonebranch4]

Hi Isomorphic,

The compact calendar is not showing the month - year, when its first loaded. We recently upgraded to v14.1 pro 06/08 version and noticed this issue.
The show case also having the same issue.
https://smartclient.com/smartgwt/sho...endar_category


Can you please fix this issue.

Thanks

[Isomorphic]

Thanks for the report - this has been fixed for tomorrow's builds, dated June 19 and later.

[stonebranch4]

Thank you for the quick response. We also found the following issues with the calendars.

1. Refresh does not work.
2. Calendar entries are not loaded at the first time. if we go front and back then its loading.
3. If you click on right arrow (>) and then click on the left arrow(<), disables the left arrow.

Can you please looks in to these too.

Thanks

[Isomorphic]

We don't see any issues like this.

Please be precise about which sample you see doing this, and your OS and browsers (and device, if you're on mobile).

If you don't see this in a showcase sample, show a test-case we can run.

Note - if you are still using the same online 14.1 sample you mentioned, compactCalendar, then data does show right away (but you have to scroll the view down a bit because the "longEvent" layouts are incorrectly present, and that makes each row a bit taller - we've removed them for today's builds) - going backwards and forwards also works in Firefox and Chrome, with no icons becoming disabled.

[stonebranch4]

Thank you for your quick response. We will test with the new build and get back to you on this with sample code.

We have noticed one more issue.
Can you please let us know, if the Class for a RadioGroupItem changed for locators?
They are now showing up as "...||Class=RadioItem]/element", where prior they showed up as "...||Class=CheckboxItem]/valueicon".

Appreciate your help on this.

Thanks

[Isomorphic]

Can you confirm which version you upgraded from? Were you already on 14.1 or was it an upgrade from an older branch, like 12.1?

Also, which skin are you using? Whether one of ours or a custom one, can you confirm the value of RadioGroupItem.useNativeRadioItems?

[stonebranch4]

Hi,

We are upgrading from v14.1p_2025-04-04 to v14.1p_2026-06-08 and using 2 different skins, Obsidian and Stratus. It is working good in Obsidian and changed for Stratus.
For Obsidian we are setting like this

isc.RadioGroupItem.addProperties({
useNativeRadioItems: false,
height: 22,
textBoxStyle: "staticTextItem",
cellStyle: "labelAnchor"
});

But for Stratus we did not specified the property.

isc.RadioGroupItem.addProperties({
height: 22,
textBoxStyle: "staticTextItemLite"
});


Can you please let us know if something got changed if we don't specify the property?

Thanks

[Isomorphic]

The problem here is definitive - we can see from the config you showed that you still have the old version of Stratus, and not the one that shipped in the May 8 build that you updated to.

In fact, your Stratus skin is more than a year old, and this is provable because we added useNativeRadioItems: false to that skin (and all the other Flat skins) on April 24, 2025 - this was so we could scale and colorize radio-images reliably, which remain limited capabilities for native radios. Since your old version was from April 4 2025, 20 days before we made this change, you presumably either: haven't properly updated your framework, have a sperate copy of Stratus in some other place, still have the old framework in the path, or perhaps your app is running from a bundle that hasn't been rebuilt.

Separately, on the matter of Locator-strings - it has always been the case that useNativeRadioItems affects the locator-string; and there was always a bug where a radio-locator recorded in a skin with that property set to true would fail to locate in a skin with it set to false, and vice-versa.

That bug was also fixed and ported back to 14.1, this time on April 1 2026, about 10 weeks ago.

[stonebranch4]

Thank you for the clarification about the locators & skins.

Related to the calendar issue, we noticed that it used to fire addDateChangedHandler event, when its first loaded in v14.1p 2025-04-04, but with the latest version its not firing this event.

Can you please look into this and let us know if it can be fixed in the next build.

Thanks

[Isomorphic]

In recent versions the Calendar's databinding was reworked so that it now complies with the DataBoundComponent contract, which previously wasn't fully the case. As far as we can tell dataChanged never fired on initial load anyway, but if it did, that was a bug rather than intended behavior.

The relevant rule: for a databound component, data arriving from the initial fetch fires dataArrived(), not dataChanged(). That holds across the framework - dataArrived means "rows came back from the server" (initial load or paging), whereas dataChanged means "the dataset was modified", ie an add/update/remove against the cache, or a fresh setData(). The two carry different signatures for exactly this reason (dataArrived gets startRow/endRow; dataChanged gets operationType/record/rowNum).

So the correct hook for "the initial data has loaded" is dataArrived(). If you just want a one-shot notification when a fetch completes, pass a callback to fetchData().

One thing worth checking on your side: the same rework made the Calendar honor autoFetchData like other DBCs, so it no longer issues a fetch on draw unless autoFetchData: true (or you've called fetchData() yourself). If your data simply isn't showing up on load anymore, that's almost certainly the cause - set autoFetchData: true.

[stonebranch2]

Hi,

We are upgrading from v14.1p_2025-04-04 to v14.1p_2026-06-08 and using 2 different skins, Obsidian and Stratus. It is working good in Obsidian and changed for Stratus.
For Obsidian we are setting like this

isc.RadioGroupItem.addProperties({
useNativeRadioItems: false,
height: 22,
textBoxStyle: "staticTextItem",
cellStyle: "labelAnchor"
});

But for Stratus we did not specified the property.

isc.RadioGroupItem.addProperties({
height: 22,
textBoxStyle: "staticTextItemLite"
});


Can you please let us know if something got changed if we don't specify the property?

Thanks

Hi Isomorphic,

My apologies, when I grabbed these originally, I didn't realize I had already switched off the feature branch.

The feature branch has the latest skin applied from Version v14.1p_2026-06-08/LGPL Deployment - 2026-06-08.

Sorry for the confusion.

Stratus



Obsidian

[stonebranch2]

The problem here is definitive - we can see from the config you showed that you still have the old version of Stratus, and not the one that shipped in the May 8 build that you updated to.

In fact, your Stratus skin is more than a year old, and this is provable because we added useNativeRadioItems: false to that skin (and all the other Flat skins) on April 24, 2025 - this was so we could scale and colorize radio-images reliably, which remain limited capabilities for native radios. Since your old version was from April 4 2025, 20 days before we made this change, you presumably either: haven't properly updated your framework, have a sperate copy of Stratus in some other place, still have the old framework in the path, or perhaps your app is running from a bundle that hasn't been rebuilt.

Separately, on the matter of Locator-strings - it has always been the case that useNativeRadioItems affects the locator-string; and there was always a bug where a radio-locator recorded in a skin with that property set to true would fail to locate in a skin with it set to false, and vice-versa.

That bug was also fixed and ported back to 14.1, this time on April 1 2026, about 10 weeks ago.

See my response above. Sorry for the confusion.

[stonebranch4]

Hi,
Can we please have an update on the skin issue?

Thanks

[Isomorphic]

Which skin issue? We responded fully in post #10.

[stonebranch4]

Hi,

Sorry there was a confusion and we sent the wrong details. can you please check the post#11.

Thanks