CODEWITHSUNDEEP
c#winformsperformanceuser-controls
psurikov
psurikov

Reputation: 3458

How to avoid a large number of user controls on a form

I'm creating a user control that represents a list of other custom controls (they are pretty simple: include label, checkbox, icon and button). When I place it on a form it takes to long to load all of the list items (there are 100 - 150 items in a list). What are the alternative ways for displaying a list of custom controls of a large number?

I tried to use SuspendLayout and ResumeLayout but it didn't help much, using them reduces the time, but its still too long.

There are some ideas I cannot implement for various reasons:

Grateful for any advice

EDIT:

There were a few suggestions to use a DataGridView. This is a good idea, but the problem is that the custom control can change it's size and show additional information below (it behaves like expander). It's not easy to do with DataGridView

Upvotes: 4

Views: 1878

Answers (4)

Lane
Lane

Reputation: 2719

If you are tied to WinForms, then I highly recommend that you use a DataGridView instead. I ran into the same issues a while ago, and found that the DataGridView was extensible enough to list all sorts of controls (TextBoxes, CheckBoxes, even DateTimePickers, etc). Transitioning to this control sped up my UI tremendously, and was more stable and easier to maintain.

If you need more advanced facilities in each row, like the Expander properties you mentioned, then I think you should look into WPF. With WPF you have tremendous flexibility to completely design your UI controls the way you want them, and the performance is still very good.

If neither of these work for you, then how about redesigning your UI? As mentioned, there is no way to alleviate the performance hit for a large number of controls. So how about show one row or only a few rows at a time, with a filter or search facility to allow the user to find the row(s) they want. Or, show all rows but only use minimal controls in each row, and have the user doubleclick on the row to bring up a dialog window to display more detailed information about the row? Some way or another you'll have to cut down the number of controls initially displayed. These are just a few ideas.

Upvotes: 2

Sorin Comanescu
Sorin Comanescu

Reputation: 4867

Use a DataGridView and customize columns?

Upvotes: 0

Steve
Steve

Reputation: 31642

I agree with @Cody, but, in case "stripping some of the ones that you have out" isn't an option... let me take it one step further...

You mentioned you have a list.

I'd take a hint out of the iOS playbook, and only have the number of controls active that you need to display the list on the screen.

For example; If the list has room for 30 items on the screen, you can re-use the same 30 controls as the user scrolls / pages through the list.

Which brings up another point - sometimes slightly modifying the navigation is a good bet. If you have one huge list now, maybe a "paging" features where you only display x number of items per "page" is something to consider.

Regardless, when you get to this point in an application, and you have real world loading speed / memory usage performance requirements, it's time to crack out the old book on performance tuning, and implement proven patterns like re-use, caching, etc. It's usually not always pretty, and it makes your solution more complex, but you do what you need to do to make it work right.

Upvotes: 1

Cody Gray
Cody Gray

Reputation: 244812

Unfortunately, there's no way to get something for nothing. Things in life don't come for free. If you have an unreasonable number of controls on your form, you'll have to pay for the time it takes to load them. The only option is to use fewer controls.

Whether you accomplish that by stripping some of the ones that you have out, or by custom drawing lighter versions of the built-in counterparts, is up to you. But I highly recommend that you stick with the native controls and just ditch a few of the ones you're using now.

In addition to the obvious performance problems, the scenario you've described is guaranteed to create a User Overflow error, one that no debugger can fix.

Upvotes: 1

Related Questions