proper way to refresh scheduler to not leak memory

[John]

Using version 2013.3.1127.40

Hi, i have a huge memory leak in the scheduler and am trying to figure out how to fix it.
I have a scheduler that's grouped by resources.  It's a medical application, the scheduler shows appointments.

On each appointment, i have heavily customized it with stack panels and buttons/labels etc to show different statuses and allow users to interact with it.  I do this in the schMain_AppointmentFormatting event.

The data is bound via a bindinglist of a custom objects i created.

The scheduler also refreshes itself on a 1 minute timer to get changes/new appts etc.
the refresh method clears the bindinglist and repopulates it.
I do this between a 
schMain.Appointments.BeginUpdate();
and
schMain.Appointments.EndUpdate();
schMain.SchedulerElement.Refresh();

eventually after about 35 refreshes the app locks up with an OOM.  There's nothing open in the app other than the scheduler which is just sitting there refreshing itself.  
I put a memory profiler on it and it appears all the custom stacklayoutpanel and labels etc i put on the appts aren't being cleaned up.  If there are 40 apps on the scheduler, after 30 refreshes i end up with thousands of labels still in memory,  10's of thousands of radpropertyvalue etc.

What's the correct way to dispose of my custom stuff when it gets redrawn?
I attached a shot of ants profiler with some of the leaked data if it helps.
Thanks!

[John]

More information:
I took out all my custom stuff and just let the scheduler show the standard office blue and the leak isn't as bad but there's still a decent sized leak there.
the shot below is 10 refreshes.  the base line is just the scheduler sitting there open before refreshes.

Thanks

[Ivan Todorov]

Hello John,

Thank you for contacting us.

Apparently the leak is caused by RadElements left uncollected. RadPropertyValue holds the value of properties our theme mechanism applies and usually these property settings are the larger part of the memory a single RadElement takes. For this reason they appear first in the profiler. The amount of memory taken is different between different themes because themes might have different number of property settings defined.

Usually, RadElements get disposed recursively and you don't have to do this manually. However, there are several cases that might cause the leak:

1. If you subscribe to an event handler of living object, the subscriber cannot get released by the garbage collector until you have unsubscribed from the event. For example, if you subscribe to Form1.SizeChanged and the handler is a method of any of your custom elements, this custom element won't get released while the form lives as it needs to fire the event handler.

2. If you are using timers in any of your objects, you should stop and dispose them when the object is disposed. Timers are special objects that cannot be collected while active and their Tick handler will retain your object.

3. It might be the case that you are creating more objects than the garbage collector can collect. AppointmentFormatting is an event that fires quite often, not only when an AppointmentElement is created but also when something in the appointment changes. So you might just be creating to much objects. To avoid that you can try creating a custom AppointmentElement (a derived class), create a factory that implements the IAppointmentElementFactory interface to instantiate your custom appointments, then set the factory to the AppointmentElementFactory property of RadScheduler.

I hope some of the suggestions will help. If you are still facing difficulties, please send me a sample code which demonstrates your scenario. This way I will be able to provide you with further suggestions.

Regards,
Ivan Todorov
Telerik