none
Suspend/Resume layout of controls RRS feed

  • Question

  • Hi,

    Ive got a container with a bunch of child textboxes stacked using dock top. My code updates the textboxes and they vertically expand/contract etc. I'm thinking that my code might run faster if I turn off the layout refreshing until all the updates to the textboxes are done.

    I'm getting confused with what I'm reading about suspend/resume layout - do I need to suspend for ALL the child controls, then go through them all at the end and Resume individually?  

     

    Friday, July 16, 2010 7:31 AM

Answers

  • I've finally found info on the net that gives what I want ...

    'Put this in form declarations ...
    Declare Function LockWindowUpdate Lib "user32.dll" (ByVal hWndLock As IntPtr) As Boolean
    
    'To stop updates to window ...
    LockWindowUpdate(CType(Me.Handle.ToInt32, System.IntPtr))
    
    'To resume update to window ...
    LockWindowUpdate(CType(0, System.IntPtr))
    

     

    It works, no more flicker  :)

    • Marked as answer by Liliane Teng Monday, July 26, 2010 3:40 AM
    Saturday, July 24, 2010 10:07 AM

All replies

  • Before you start this kind of actions be sure that it helps. Thinking that something causes something is mostly the wrong way.

    Suspending the layout helps only if the controls itself are updated during the process, this is for instance the case in the ListView and TreeView, for a DataGridView or a textbox (in fact all controls where databinding is used)it makes by instance no sense as that is updated mostly in one and sometimes in two actions.

    I'm currious if you have commands like Redim, Split, or more of those in your application, those are time consumers.

    That is also for painting and database, but try first to optimize your program in the parts where there are known time spenders.

    It can also be that you put to early data to a control, which means it is painting, but that has nothing to do with the layout of that control.

    Be also aware that by instance a ListView is slower then a DataGridView


    Success
    Cor
    Friday, July 16, 2010 7:49 AM
  • Thanks Cor,

    Well I'm assuming (probably wrongly) that when a single control autosized textbox has it's text changed, then there will be a cascade of events to resize all related controls in the container. As I'm updating the text in all the controls in a For...Each loop then I don't want this cascade of events to happen for every time I update each control in the loop - I only want it to happen once, at the end of the loop, after I've updated ALL the controls - it that's possible.  

    I don't use Redim or split in this particular bit of the app.  Thanks for telling me about Listview versus Datagridview.

    Friday, July 16, 2010 12:58 PM
  • Hello Zippy67,

    Thanks for your post.

    MSDN Note: When adding several controls to a parent control, it is recommended that you call the SuspendLayout method before initializing the controls to be added. After adding the controls to the parent control, call the ResumeLayout method. This will increase the performance of applications with many controls.

    More information, please check:
    http://msdn.microsoft.com/en-us/library/system.windows.forms.control.suspendlayout.aspx

    Hope this could make you understand more.

    If you have any problems, please feel free to follow up.

    Best regards,

    Liliane


    Please mark the replies as answers if they help and unmark them if they provide no help. Thanks
    Friday, July 23, 2010 6:34 AM
  • Beside the ones I gave you, I've never seen any advantage of the suspend layout.

    Take a look at the many samples you see here for instance the current active shooting game.

    They never contain a suspend or resume layout.

    The chance is high that they hurt more than they add.

     


    Success
    Cor
    Friday, July 23, 2010 6:46 AM
  • Ok thanks, I'll follow the recommendation and see if it makes any difference :)

    Z

    Friday, July 23, 2010 7:33 AM
  • Well I don't want to bloat my code for no good reason - if it makes no difference after I experiement then I'll take the suspend/resume out again :)

    Thanks

    Friday, July 23, 2010 7:36 AM
  • That is the right attitude

    :-)

    Let us know?

     


    Success
    Cor
    Friday, July 23, 2010 7:40 AM
  • Well, I can see no difference by using suspend/resume layout.

    My actual form is quite complex. I'm updating controls on a Panel1 that is nested as follows :

    Form > TableLayoutPanel1> TabControl1 > TabPage1 > TableLayoutPanel2 > Panel1 (where I am adding controls)

    I've tried nesting my suspend and resume statements, but it doesn't seem to have any effect on the display of the controls.

    For example, when I remove all the textbox controls on Panel1, I can visibly see them being removed - it's quick, but they don't just 'go'. So it looks like the paint events aren't suspended on Panel1.

    I just wish there was a simple command to say 'stop repainting this container (and sub-containers/controls - I don't want to have to think about what nesting of containers I've got :)'. 

    Saturday, July 24, 2010 9:29 AM
  • I've finally found info on the net that gives what I want ...

    'Put this in form declarations ...
    Declare Function LockWindowUpdate Lib "user32.dll" (ByVal hWndLock As IntPtr) As Boolean
    
    'To stop updates to window ...
    LockWindowUpdate(CType(Me.Handle.ToInt32, System.IntPtr))
    
    'To resume update to window ...
    LockWindowUpdate(CType(0, System.IntPtr))
    

     

    It works, no more flicker  :)

    • Marked as answer by Liliane Teng Monday, July 26, 2010 3:40 AM
    Saturday, July 24, 2010 10:07 AM
  • Zippy,

    Fine but like I've more written to you, would you not look to your design instead of adding all kind of plasters.

    For sure you will become again in trouble sooner of later like it is now.

    You wrote complex, a good program is never complex.

    The goal can be complex but even than the desing has to be transparant for everybody who've to maintain the programs.

     


    Success
    Cor
    Saturday, July 24, 2010 11:10 AM
  • Well, I can't see how having a nested set of containers on my form can make it a bad design - maybe complex was a bad word to use. I was describing the form just in case it made any difference to the way suspend/resume work.

    Enabling/disabling Window updating isn't entirely what I wanted, because really I was hoping for a simple way to stop all system adjustment to anything to do with the layout of the controls, while my code is making changes. Then allow the system to update everything at the end. I can imagine all sorts of events are fired every time something changes, which is unecessary processing. I thought suspend layout stopped all that, but it doesn't - I found a piece of info on the net saying that it doesn't stop controls from being redrawn.  It seems many people out there have the same misunderstanding and think suspend/resume is going to work in the same way as application.screenupdating = false used to.

    At least stopping Window updating is a way of preventing flicker. However I feel it shouldn't be necessary to declare a function referring to User32.dll for something as simple as enabling/disabling screenupdating - maybe an ommission in .NET ?!!

     

    Saturday, July 24, 2010 12:20 PM
  •  

    At least stopping Window updating is a way of preventing flicker. However I feel it shouldn't be necessary to declare a function referring to User32.dll for something as simple as enabling/disabling screenupdating - maybe an ommission in .NET ?!!

     


    That would it be as we see it often, more probably is your program doing much more in a loop than you are really aware of. The flickr means in fact that something is done which is not necessary. Like I wrote you should not put a patch on it, you should make it new. Like a tire with hundreds of patches, it runs, but not as it can be and at someday you get another problem.

     


    Success
    Cor
    Saturday, July 24, 2010 4:01 PM