-2

I have a large form with many controls on it(50+). The logic to show all of these isn't complex at all, just a few checks here and there depending on the user. I've tried implementing a backgroundworker and however it loads faster, the controls still are lagged and await the UI thread to complete before loading the controls that were thrown into the backgroundworker. Are there any other options out there? Just looking to see what type of options are out there for 3.5 :)

Criel
  • 805
  • 1
  • 14
  • 32
  • Would converting over to WPF take some time? And is it compatible with vb.net forms? The rest of the application is in vb.net, so there's that concern :) – Criel Aug 09 '13 at 17:50
  • What's slow and laggy? WinForms can be fast, but it can be slowed down tremendously if you have incorrectly-placed data-loading code or slow control painting routines. Please tell us how you are "loading" these controls. Also, have you tried using Release instead of Debug? – Dai Aug 09 '13 at 17:50
  • 2
    @HighCore - "*winforms does no support big UIs*" What? Where'd you get that? WinForms has fantastic support for big UIs. WPF was developed for better maintainability (by making proper architecture easier to use), but WinForms scales just fine if you apply a good architecture to it. I've seen WinForms with hundreds and even thousands of controls that work just fine. – JDB Aug 09 '13 at 17:52
  • @Dai - we get the information from a backend system. So querying that 50some times could result in a little bit of lag getting the information but I do think it needs a little TLC to get it up where it should be. Could you explain a little more on 'control paining routines'? – Criel Aug 09 '13 at 17:55
  • 1
    @Criel - Unfortunately, the issues you are running into cannot be fixed with a simple setting or a little tweak. You are looking at systemic issues in how you are loading your data and your forms. You are going to need to learn more about those subjects and then take a step back and design it out to reduce UI lag time. That may mean progressive loading of data on a background thread or breaking your massive form out into multiple pieces. Blindly switching to WPF, though, will probably not help you. (Plus WPF has a huge learning curve.) – JDB Aug 09 '13 at 18:00
  • 1
    @Cyborgx37 - I figured that would be the case. I came into this program already being broken and needing some fixing. Reworking or reformatting would be tough to do due to the complexity of the change it would require. Just a shame it was built like this in the first place. I will continue my research, thanks all for your input! – Criel Aug 09 '13 at 18:04
  • 1
    @Criel - For example, 50 queries with a lag of only 0.1 seconds each is going to cost you 5 seconds of load time all by itself, never mind painting those controls, etc. Combining those queries into a single transaction could save you quite a bit of time, but you'd need some kind of architecture to coordinate all of that data and ensure that each control gets what it needs. – JDB Aug 09 '13 at 18:10
  • 2
    Then there are common mistakes like adding a control to a form, then moving it and then resizing it, requiring three (expensive) paints. [BeginUpdate](http://msdn.microsoft.com/en-us/library/system.windows.forms.listbox.beginupdate.aspx) can help some with that when its implemented. (Or just set the visibility of the control to hidden, add it, move it, size it and then show it, etc.) – JDB Aug 09 '13 at 18:11

1 Answers1

0

dont load components just switch between visible true and false it will save the time you can choose what to show and what not to show during formload event

Dandy
  • 467
  • 1
  • 10
  • 33