Infragistics WinSchedule Performance Issue

Author Message
 Posted 4/17/2013 7:32:43 AM
Advanced StrataFrame User

Advanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame User

Group: Awaiting Activation
Last Login: 3/2/2020 12:19:05 PM
Posts: 595, Visits: 3,807
I'm wondering if anyone else has run into this issue. I have a form with Infragistics CalenderInfo and WinDayView controls. The CalenderInfo is bound to a SF business binding source. The DayVew is set up to group multiple owners by date. With five owners and around 1200 appointments over a two month period the data is rendered is less than a second after the business object is filled. My problem starts when I set a logical day on CalendarInfo. Once set, the same data is taking a minute and a half to render. A check with ANTs profiler shows that it's tied up in the Infragistics code, for which I don't have the source. I've filed a support ticket with Infragistics but I thought Id check to see if any other SF user has run into this. I'm using NetAdvantage 2011 vol 2 on the latest version of SF.  
Post #31981
Add to Twitter Add to Facebook
 Posted 4/17/2013 7:40:03 AM
StrataFrame Developer

StrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame DeveloperStrataFrame Developer

Group: StrataFrame Developers
Last Login: 5/16/2018 3:20:37 AM
Posts: 2,982, Visits: 2,482
We have our own custom scheduling controls in PracticeStudio.  I haven't tried to use Infragistics' controls.  You're right, though sounds like they're trying to do some extra ciphering when you group them.  

Have you tried to set the CurrentDataTable as the binding source on the control rather than the business object itself.  They might be doing some recursive enumerating or something that is more efficient in a DataTable than a BO.  That's the only suggestion that I have.
Post #31982
Add to Twitter Add to Facebook
 Posted 4/17/2013 9:02:15 AM
Advanced StrataFrame User

Advanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame User

Group: Awaiting Activation
Last Login: 3/2/2020 12:19:05 PM
Posts: 595, Visits: 3,807
HI Ben,

Thanks for the suggestion. Binding directly to the datatable cut the rendering time from 90 seconds down to 15 but that's still too slow for what I want to do. I need it to be 2 seconds max.
I'll see what Infragistics tech support has to say.

-Larry
Post #31984
Add to Twitter Add to Facebook
 Posted 4/19/2013 9:01:57 AM
Advanced StrataFrame User

Advanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame UserAdvanced StrataFrame User

Group: Awaiting Activation
Last Login: 3/2/2020 12:19:05 PM
Posts: 595, Visits: 3,807
For anyone that may use Infragistics WinSchedule in the future, it turns out that setting a logical workday on the CalendarInfo object is a relatively high overhead item. As Ben had suggested, binding directly to the BO data table improved performance but not to where I needed it. To resolve the issue I had to reduce the number of appointments that the object had to deal with by implementing lazy loading and only pulling in a subset of days at any given time. Otter than that, and the lack of really good documentation, the controls are working very well for me.
Post #31988
Add to Twitter Add to Facebook


Similar Topics

Expand / Collapse

Reading This Topic

Expand / Collapse

Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.