DevExpress Scheduler controls: big changes are coming in v15.2

11 November 2015

One of the more popular controls we have in our platforms suites is the scheduler control. Not every app needs a scheduler, but when you’re having to worry about scheduling resources and appointments, it’s invaluable.

Although everyone is pretty happy with the scheduler user interface, for a while now we’ve been getting feedback related to performance. Consequently over the past few months we’ve put in a lot of effort into speeding up the scheduler, especially with regard to rendering the layout and data (in this version) and laying down some infrastructural improvements ready for speeding up data retrieval (in a future version). Fairly early on with this exercise we determined that some of our data structures were not optimal and so had to redesign and refactor them.

First the good news: we have managed to achieve a significant performance improvement by adjusting the way the layout is calculated. For day-view-based views (that is, Day View, Work Week View, and Full Week View) scrolling the views and switching between them is a snap because response times have been significantly decreased. Appointments now scroll smoothly. We’ve tested with as many as 5000 appointments in a view and performance is smooth and fluid. To minimize the occasional “freezing” that can affect the scheduler in your app, calculations are now executed in multiple threads. This advanced asynchronous mode can be switched off if desired; however, even in synchronous mode the layout calculations are faster than before.

Unfortunately – and here comes the bad news – these changes to the scheduler’s performance envelope have had to be percolated up into the public Scheduler API. And that in turn means some breaking changes, although we have tried to minimize the number and extent of these.

The biggest change is that several classes have been abstracted out as interfaces, and we’ve introduced several others as well. For example. the most frequently used classes, such as Appointment, Resource, AppointmentDependency are now interfaces; and we’ve added the ISchedulerStorage, IAppointmentStorage, IResourceStorage, IAppointmentLabel, IAppointmentStatus interfaces. This dual approach enables us to leave any legacy code intact (pretty much) while implementing new cross-platform features. For example, different AppointmentLabel and AppointmentStatus classes (which expose IAppointmentLabel and IAppointmentStatus interfaces) exist for each platform. However, the AppointmentViewInfo.Status property now returns an IAppointmentStatus object because the AppointmentViewInfo class instances are used for all platforms and in Scheduler Reports.

Having laid the foundations for why we have breaking changes in v15.2, I do have to mention that overall the logic used in the Scheduler API has not changed, nor have most of the method and property names and their signatures. It is all very similar, such that the number and nature of the changes you will have to make in upgrading your app are small and easily made:

  • Appointment: no longer has a constructor since it’s now an interface. To construct an Appointment object use SchedulerStorage.CreateAppointment() instead .
  • Resource: no longer has a constructor since it’s now an interface. To create a Resource object, use the SchedulerStorage.CreateResource method. The static property Empty has been removed, and you should use ResourceEmpty.Resource or ResourceEmpty.Id instead, depending on the context.
  • AppointmentDependency: no longer has a constructor since it’s now an interface. You now use the SchedulerStorage.CreateAppointmentDependency method to create an appointment dependency object.
  • The AppointmentViewInfo.Status property now returns an object that implements the IAppointmentStatus interface instead of an instance of the AppointmentStatusBase class.
  • The Appointment.RecurrenceInfo property now returns an object that implements the IRecurrenceInfo interface.
  • Several properties and methods has been marked as obsolete and will be removed in a future major version. You should be aware that this is going to happen at some point and make plans to rewrite your code to avoid them. You can defer these changes until after the v15.2 major release though.
  • Until v15.2 the Appointment.StatusId and Appointment.LabelId properties were declared to be Int32s, since they were in essence an index value into the label and status collections. From the developer point of view, this choice made it really difficult to bind such labels and statuses to fields in an external database. From v15.2 onwards, the new AppointmentStatus and AppointmentLabel objects have their own Id object property which is no longer related to an index of a collection. These objects are returned by the Appointment.StatusKey and Appointment.LabelKey properties (and, obviously, can now be represented as rows in a table in a database). This should help developers who had to devise various workarounds to deal with the original problem.

Now for the new features!

1. A new feature is a Brush property for the status that enables the developer to define the brush used to visualize and display the appointment status. In fact the label color and status brush properties are platform-specific in order to utilize native brushes and colors for each platform.

2. We have implemented a new default appointment form used by your users to create an edit appointment details. This has been designed to mimic the Microsoft Outlook appointment dialog.

The new scheduler appointment form

3. The Scheduler control now can indicate the current time by drawing a line in the view. In the Day, Work-Week, and Full Week views the horizontal line can go across the entire view, or it can be restricted to the current date.

The new time indicator for the current time

In the Timeline view however, the time indicator is a vertical line drawn down the view.

The new time indicator for the current time

20 comment(s)
Nate Laff

Aaaaaaah!!! And I literally after years and years of waiting finally put in a workaround for letting users customize labels and statues. Oh well, I'm sure I'll be able to shoe horn the new interfaces in without a whole lot of work.. if only I'd waited another couple months :P

11 November, 2015
Saif Khan

Nice work, although I never understood why a schedule(er) is always/only associated with appointment. IMO it should be a reminder. In the many applications I've done using DevExpress scheduler I've never once has to use it for an appointment. Whenever my users look at a scheduler they only see reminders.

SchedulerStorage.CreateReminder()

just by two bit-cents.

11 November, 2015
Franky Brandt

Is this about the VCL scheduler or .net?

11 November, 2015
Julian Bucknall (DevExpress)

Franky: For now this is .NET only. As is common these days, our VCL team will allow the .NET teams to find/solve issues first and then will migrate this new functionality and structure over to Delphi next year.

Cheers, Julian

11 November, 2015
Neal

PLEASE use a larger font in 2015 for your articles

11 November, 2015
Aye Thein

Thanks! but don't forget to implement the print out features too.

11 November, 2015
FrankS

Sounds good!

Is there a way to get a "Preview" for the Scheduler Interfaces?

We develop a complex shift planner and would like the interfaces considered in the modeling

Regards

12 November, 2015
Johnny K

Omg finally labels and status are done properly.....!!! So happy with that but also

Omg i have to see in my old code wtf workaround solutiona i have done in my projects and see how can i undo them bow and implement the proper id properties....that will be hard! :-/

12 November, 2015
Alan Johnson

I like the display of a line to indicate the current time on the timeline view but is there an option to draw the line over the appointments rather than behind them - it does it on the other views!

12 November, 2015
Julian Bucknall (DevExpress)

Alan: As it happens, in the Scheduler for WinForms 15.2 we've implemented the TimeIndicatorDisplayOptions.ShowOverAppointment property. The TimeIndicatorDisplayOptions object is returned by the TimeIndicatorDisplayOptions property of the DayView, WorkWeekView, FullWeekView and TimelineView views.  The ShowOverAppointment property specifies whether the Time Indicator (our term for the current time line which goes across the view) is displayed over appointments in the view. If the option is set to false, the Time Indicator is drawn behind appointments.

So ... yes. :)

Cheers, Julian

12 November, 2015
Henning Scharsach

Great news!!!! We've been struggling with Scheduler performance for large datasets for quite some time now (on the data as well as the visualization level), but realizing that some major refactoring would be necessary to tackle these issues, I didn't have high hopes to see big changes anytime soon ...

It's great to see that DevExpress is not resting on its laurels, but still strives to make a good product even better - even if that means introducing some breaking changes!

Keep up the good work guys! :-)

12 November, 2015
Peter DeSantis

Are these changes for the scheduler control the same and available for ASP.net, and WPF or are they only for winforms ?

12 November, 2015
Matthias Adloff

This is amazing news. If it really is like you say, we will swallow the 'breaking changes' pill, since it was expected to be swallowed. To be honest were very close to removing the scheduler because the performance was simply not acceptable with only a few hundred entries loaded by a selective query mechanism. This control was the most-complained one by almost all of our customers.

I'm pretty curious!

2 December, 2015
Mark Thomson

Julian, the changes you talk about here are not mentioned in the DevExpress webpage Breaking Changes in 15.2.3. I think this is a serious oversite. If I had not seen this blog, the changeover from version 15.1 to 15.2 would not have been very smooth. However, the changeover was smooth, with the exception of one issue, for which I have raised a ticket. The issue had nothing to do with these changes. I look forward to doing some load testing.

10 December, 2015
Bernd Niedergesaess

What will happen with an existing scheduler calendar file which was written with v15.1 or v14.2 (using schedulerStorage.Appointments.Items.WriteXml) and is now read-in with the v15.2 ?

Here it seems, that this is not really possible?

So how to migrate this?

15 December, 2015
Oleg (DevExpress Support)

Hello Bernd,

We have tested several scenarios regarding loading appointments from XML files, which were created in previous versions (15.1 and 14.2) but we were not able to detect any issues. Appointment labels and statuses are correctly exported from XML files in version 15.2.

In any case, if you experience any issues regarding migrating to version 15.2, you are welcome to submit a ticket in our Support Center, and our Support and R&D teams will do their best to assist you.

The only difference between versions 15.1 and 15.2 is that in case of empty labels and statuses (i.e. when there is no corresponding information in the loaded XML file), the LabelId and StatusId properties return 0, LabelKey and StatusKey return null.

16 December, 2015
Oleg (DevExpress Support)

As a follow-up,

We have found the issue with initializing the LabelKey and StatusKey properties after loading appointments from an XML file, which does not contain the "Label" and "Status" attributes.

We are going to fix this issue in the scope of the following thread:

www.devexpress.com/.../T325085

16 December, 2015
SpaceTeam

My was working scheduler application is now absolutely not working with many changes that I have to carry out. Appointments now appear then when I click to another date and go back to the original date they don't reappear. This is creating a lot of work, I feel this could have been handled better!

2 January, 2016
SpaceTeam

This is a BREAKING change that's for sure !

2 January, 2016
Chris Royle (LOB)

Here's some information which might help others. I found it very hard to find this blog, and the workaround code  - www.devexpress.com/.../T306810

Changing classes to interfaces and not prefixing the interface names with an I seems an odd choice.

5 February, 2016

Please login or register to post comments.