Hi -
We are experiencing an issue, which I am able to reproduce in your demo, where creating a recurring event that has a duration greater than its frequency causes rendering issues. For example, an event that is a week long and happens every hour. More extremely, try this scenario:
1. Create a new event with a start of 9/14/2005 11:00 AM and a finish of 9/14/2012 1:00 PM.
2. Add hourly recurrence (recurring once every hour).
3. Navigate to some date in the scheduler that comes before 9/14/2012.
The above scenario, while I realize it is unrealistic in a practical sense (but of course, everyone has users who will try it), causes the recurring events to overlap and ultimately "stack up" to epic proportions. It crashed my browser when I tried it in your demo. The same thing happens in our application, and we are getting this error as well (which I imagine you may have seen in your own error logs when I tried it in your demo):
Looking at the exception, it looks like what might be happening is that your code is trying to determine how tall the control needs to be based on how many events need to be rendered, and the .NET Unit structure itself is saying "that's too big."
Microsoft Outlook enforces a rule with recurrence where duration must be less than or equal to frequency. That solves this issue. Is there any reason the RadScheduler doesn't do the same?
Is there any known workaround here or are we expected to code our own validation for this on top of the RadScheduler?
Thanks,
John
We are experiencing an issue, which I am able to reproduce in your demo, where creating a recurring event that has a duration greater than its frequency causes rendering issues. For example, an event that is a week long and happens every hour. More extremely, try this scenario:
1. Create a new event with a start of 9/14/2005 11:00 AM and a finish of 9/14/2012 1:00 PM.
2. Add hourly recurrence (recurring once every hour).
3. Navigate to some date in the scheduler that comes before 9/14/2012.
The above scenario, while I realize it is unrealistic in a practical sense (but of course, everyone has users who will try it), causes the recurring events to overlap and ultimately "stack up" to epic proportions. It crashed my browser when I tried it in your demo. The same thing happens in our application, and we are getting this error as well (which I imagine you may have seen in your own error logs when I tried it in your demo):
System.ArgumentOutOfRangeException: Specified argument was out
of the range of valid values.
Parameter name: value
at System.Web.UI.WebControls.Unit..ctor(Double value, UnitType type)
at Telerik.Web.UI.Scheduler.Views.SchedulerAllDayTable.CreateAllDayCells(WebControl row, Dictionary`2 appointmentControls)
at Telerik.Web.UI.Scheduler.Views.SchedulerAllDayTable.AddRow(IList`1 allDaySlots, Dictionary`2 appointmentControls)
at Telerik.Web.UI.Scheduler.Views.Week.Renderer.CreateAllDayContent(WebControl allDayContentWrapper)
at Telerik.Web.UI.Scheduler.Views.Week.RendererBase.AddAllDayRowContent(SchedulerTopTable topTable)
at Telerik.Web.UI.Scheduler.Views.Week.Renderer.GetInnerContent()
at Telerik.Web.UI.Scheduler.Views.Week.Renderer.GetContent()
at Telerik.Web.UI.RadScheduler.CreateContent()
at Telerik.Web.UI.RadScheduler.CreateChildControls(Boolean bindFromDataSource)
at Telerik.Web.UI.RadScheduler.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Looking at the exception, it looks like what might be happening is that your code is trying to determine how tall the control needs to be based on how many events need to be rendered, and the .NET Unit structure itself is saying "that's too big."
Microsoft Outlook enforces a rule with recurrence where duration must be less than or equal to frequency. That solves this issue. Is there any reason the RadScheduler doesn't do the same?
Is there any known workaround here or are we expected to code our own validation for this on top of the RadScheduler?
Thanks,
John