Based on your feedback over the years, for Q2 2014 we decided to fundamentally enhance RadScheduler. Of course, we did this with backwards compatibility in mind as we didn’t want to break your existing applications. So if you are eager to learn more about the changes we have made and the features we have introduced, please read through.
Why we made the decision
If you are familiar with other controls from the UI for WinForms suite, you are probably aware of the rich customization abilities they provide. However, RadScheduler was to some extend missing part of this flexibility and was designed more like a closed end-to-end solution. Another interesting fact about RadScheduler is that it is the second most widely used component after RadGridView. Therefore, we were getting lots of how-to questions about achieving various custom scenarios.
The approach we took
The good thing about the old design was that it was really closed to extensions. This allowed us to replace almost entirely the code in the UI layer but keep the element structure and the public API the same. Basically, we were able to implement the improvements by keeping the number of breaking changes to the minimum. The benefits – more consistent behavior in the UI layer, improved performance and the ability to access, extend, modify or replace almost every element in the structure.
Under the hood
Summarizing the above, the new version of RadScheduler looks exactly like the old one, but all things and processes behind its visual appearance now flow in a different way. We’ll go through a few specific examples of what’s changed.
The first thing we revised was the lifecycle of the elements. If you’ve ever tried to access and modify any child element of RadScheduler, you would know that because of the selective updates it was performing there was no reliable way to keep these modifications. In the new version, it is guaranteed that the non-recyclable elements (all elements except the cells and the appointments) will stay the same until the next ActiveViewChanged event. Therefore, it is sufficient to use only this event to apply your modification to the element tree. This stands for all views including the grouped ones. For example, here is how you can increase the width of the scrollbar in DayView by handling the ActiveViewChanged event:
sender, Telerik.WinControls.UI.SchedulerViewChangedEventArgs e)
SchedulerDayViewElement dayViewElement =
Additionally, now all elements are created through the SchedulerElementProvider. By replacing the default provider you are now able to replace any of the scheduler’s default elements with your custom ones. SchedulerElementProvider also handles caching and reusing the recyclable elements SchedulerCellElement and AppointmentElement. This improves the performance in the cases where these elements need to be reinitialized.
The selection of cells and appointments is another part that we have reworked entirely. In the previous version each element had its own selection API and implementation. So if you wanted to manipulate the selection programmatically, you would’ve probably had to check in which view you are, then access the desired element to call the selection, then synchronize it with the other elements and so on. Now the selection is entirely handled by the SchedulerSelectionBehavior. You can use its API to manipulate the selection programmatically or you can even replace it if you want to change the default behavior of the selection. As a little addition, you now get the AllowAppointmentMultiselect property which enables the end user to select multiples appointments at once.
Another similar behavioral component is the SchedulerInputBehavior. It unites the input handling logic in one place and allows you to easily send input commands programmatically, no matter in which view RadScheduler currently is. In addition, it allows you to modify the default behavior and implement custom functionality like the one demonstrated in the documentation article.
Going the extra mile
After we were done implementing the changes we wanted, we decided that the time is great to go ahead and try to address as much of the logged items from our Feedback Portal as we can. As a result, almost all of the issues are now resolved, and, a bunch of new features requested by you were implemented.
One of the most requested features was the ability to modify the size of columns, rows or resource views. Using the SetResourceSize method it is now possible to specify the relative size of child resource views. You just need to specify the index of the child view and the relative factor you want to multiply its width by:
Setting this will give you the results below:
Similar methods (SetColumnWidth, SetRowHeight) are available for all view elements.
We’ve also made some improvements to the drag&drop and resize functionalities. It is now possible to drag or resize an occurrence of recurring series and this will mark the occurrence as an exception.
Additionally, the AllowViewNavigationOnDrag will enable your users to drag an appointment to a date which is outside the current view. Just set this property to true and drag an appointment outside of the control’s bounds. The date of the active view will automatically change.
Last but not least, there were a couple of requests for adding scrollbars to different areas of RadScheduler to allow easier navigation and appointments handling. The first request was for a scrollbar in the AllDayArea to allow scrolling when there are many all day events. The second request was for a scrollbar in the Month View which would allow the user to quickly navigate over large intervals of time. So there they are.
These are just a few of the new features of WinForms RadScheduler. For a list of all changes please visit theRelease History page.
Hope you like the new old RadScheduler. As always, you are welcome to share any feedback.