We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
close icon

4 bugs when FirstDayOfWeek set to monday (for European coutries), and 3 other bugs

Tested on Anroid 4.4 set in French.

* When FirstDayOfWeek is set to Monday (ie: 1) :
- in month mode, the first column is still sunday.
- in work week mode, monday is the first column, but all ScheduleAppointment are shifted by one day (ie an appointment on 01/12 appears in 01/13 column)
- in week mode,  the first column is still sunday.
- in day mode, it works fine.

* WeekViewSettings / WeekLabelSettings / TimeFormat has no effect (but WorkWeekViewSettings / WorkWeekLabelSettings / TimeFormat does work fine in workweek view).

* On "Small" android screen height
On a Samsung S3 (GT-I9305) screen the month text in the header line is cut (views: month, workweek, week and day). On Samsung S5 it appears fine. A workaround is to change HeaderStyle / TextSize to a smaller value (but it becomes ugly).
On a Samsung S3 the column titles in the second header line are all cut (views: workweek, week and day). On Samsung S5 they appear fine. No workaround.

    "Syncfusion.Xamarin.SfSchedule": ""

5 Replies

SP Sivakumar Punniya Moorthi Syncfusion Team January 16, 2017 09:59 AM UTC

Hi Benjamin, 
Thanks for using Syncfusion Products. 
Query #1: 
 Regarding FirstDayOfWeek” the first column is still sunday 
Based on your provided information when we set the first day of week is 1, Sunday will be FirstDayOfWeek which is a default value, below values are used to set the first day of week, 
Reagrding WorkWeek Appointment Rendering: 
We have created a support incident under your account to track the status of this issue. Please log on to our support website to check for further updates. 
Query #2: 
Based on your provided information, we are unable to reproduce the mentioned issue "Time Format was not working in Schedule Views (Expect WorkWeek view)". Could you please provide us more information along with Simple issue reproducing sample? It will be very helpful for us to analyze on it and provide you the possible solution. 
Query #3: 
We have already considered and fixed the resolution based issue on various device. The fix for this issue will be available in our upcoming Vol 1 release. Which expected in the mid of February. We appreciate your patience until then. 
Note: HeaderHeight and ViewHeaderHeight properties can be used to Set the adjust header height and view header height based on your requirements. 
Sivakumar P 

BM Benjamin Mayrargue January 16, 2017 10:42 AM UTC

 Regarding FirstDayOfWeek” the first column is still sunday 

I updated my code to use 2 instead of 1 based on your return. Note that this is not the .NET standard way as explained in CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek documentation.
This setting fixed the bug.

> Query #2:  

Invalid, can not reproduce issue.
But the value from CultureInfo.CurrentCulture.DateTimeFormat.ShortTimePattern can not be used as TimeFormat pattern.

> Query 3:

workaround does work.

SP Sivakumar Punniya Moorthi Syncfusion Team January 17, 2017 08:56 AM UTC

Hi Benjamin,

Thanks for the update.

Query #1 & Query #3:

We are glad to know that you have met your requirement.

Query #2:
Since the shared information was not sufficient to reproduce the reported issue, Could you please elaborate your requirement and provide a simple issue reproducing sample and its replication procedure along with it?
It will be very helpful for us to understand your requirement clearly and update the response.

Please let us know, if you require further assistance on this.

Sivakumar P


BM Benjamin Mayrargue January 17, 2017 09:46 AM UTC

I can not reproduce Query #2. Closed.

Query #4:
The value from CultureInfo.CurrentCulture.DateTimeFormat.ShortTimePattern can not be used in the TimeFormat field.
I'm unable to display "16 h" using any TimeFormat pattern for example.

SP Subburaj Pandian Veluchamy Syncfusion Team February 13, 2017 11:04 AM UTC

Hi Benjamin,

Sorry for the delayed response.

We have analyzed your requirement of setting Schedule TimeFormat as “16h” in Xamarin Forms, while setting TimeFormat (example “h”) it has converting to TimeFormat based on the given characters which is an expected behavior. Since the mentioned escaping character support is not available, we have considered this as a feature request and logged feature report for the same. We will implementation this requirement in any of our upcoming volume release.

Subburaj Pandian V.

Live Chat Icon For mobile
Up arrow icon