Maybe I'm hallucinating, but I could swear in the good old days (pre-.NET, that is), there was a way to suppress a form refresh (AutoRefresh/AutoRedraw form property?) when interface changes were made. This required manually issuing a form.Refresh upon completing changes to ensure the new interface was then displayed, but allowed me to make multiple changes to the interface and the user would only see one update with all changes made simultaneously. I used to do this with multimedia programs I was working on at the time in VB3, as I recall.

Code I've written for a .NET Windows application is selectively hiding, unhiding, enabling, and/or disabling some 70-80 interface objects and the form appears to be refreshing after each one is changed. The coolness factor of watching each object appear or disappear in order on the screen goes away rapidly after the 3rd or 4th time through. I also believe the automatic refresh after every interface change is slowing down processing as well, particularly considering the number of objects on the form that are redrawn every time. This even seems to be occuring when the form is first displayed, leaving large white spots on the form until the details for each object are filled in. Very ugly, IMHO.

So, is there some way to suppress the form refresh until all my interface changes have been made, so that the screen just refreshes once, instead of after each change? Has AutoRefresh been renamed something obscure that's now 15 levels deep in form object property references, has it been removed because Uncle Microsoft knows what's best for us, or am I confused about what I used to be able to do?

Hi Ron,

I have no real idea what I am talking about when it comes to refresh / redraw / repaint issues with Windows Forms, so I could be completely wrong, or offer you something you cannot use, but you may want to take a look at methods like SetStyle. SetStyle is defined in the Control class, and ultimately (or actually, somewhere half-way up) Form inherits from that class.

SetStyle accepts a ControlStyles enum, like ControlStyles.UserPaint and / or ControlStyles.DoubleBuffer. These enums are there to control the way the screen is refreshed / redrawn, and are generally used to avoid flicker.

Unfortunately, I do not have a complete and working solution, but these keywords may get you in the right direction. This is another of those things in .NET that is made much harder than it used to be, to provide (probably) a much more flexible solution.....

Don't get disappointed when Me. or this. doesn't pop up intelli sense for the SetStyle method; it's there, although you cannot see it.

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Imar,

Your suggestion is SO close! It removes all the objects at the same time, with only one screen refresh, which is what I wanted. Very clean! But making the objects visible again still flickers as each object is drawn. It's also still flickering when the form is initially painted.

I've thought, relative to the initial paint, that SetStyle simply may not be executed early enough. I inserted it before the call to InitializeComponent in the form NEW, as I was under the impression that InitializeComponent was the place where the objects were being instantiated to the form and setting this before object instantiation would prevent the flickering even on form load. But that didn't seem to help. I tried moving it before MyBase.New, but that caused an error saying that MyBase.New has to be the first line of code in New (begging the question of why it's even a statement if it always has to be in a specific place in code, but that's not important here).

I'm not very familiar with the order of events in .NET forms, but can't think of any place earlier in code to place it so this may be as close as I can get to a solution. Or maybe SetStyle simply doesn't work when displaying objects, only when hiding them?

In any case, thanks for the clue! It solves my problem 1 out of three times, anyway, although I'd most like to lose the flicker in the initial form paint, as that's when it will be encountered most often.

The idea behind MyBase.New being the first line of code in a constructor is that as soon as you create a derived class, it's important that you initialize its parent (that's how things work in OO; as soon as you create a derived class, its parent is called. Then that parent calls the constructor of his parent, and so on, all the way up to object.

However, you could decide to *not* call the parent constructor. Usually, this is not recommended as you may end up with an object in an undetermined state, but there are situations where it might be useful. So, if you didn't have to include the statement at all, there is no way to not call it if you didn't want to. But if you *do* want to call it, you have to call it as the first statement in your constructor method. (Still with me? I am sure there are better ways to explain this....)

I was thinking about this issue yesterday, and I thought that maybe you can override the onpaint event. Whenever onpaint is called, simply do nothing, but call your own paint method whenever you're done updating the UI. Not sure if that will work, and how messy it is, though.

How many controls do you have on your form? Can you embed them in a container control, like a panel? Then you could do something like this:

Me.Panel1.Visible = False
' Do loads of updates here
Me.Panel1.Visible = True

From what I can see, this would result in 1 single paint action, that will take place when you show the Panel. Does this help?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Winnebago Warrior by Dead Kennedys (Track 8 from the album: Plastic Surgery Disasters + In God We Trust) What's This?

Imar suggested:

How many controls do you have on your form? Can you embed them in a container control, like a panel? Then you could do something like this:

Me.Panel1.Visible = False
' Do loads of updates here
Me.Panel1.Visible = True

From what I can see, this would result in 1 single paint action, that will take place when you show the Panel. Does this help?

Ron's response:

Funny you should suggest this as I was just trying it before I received your post. It worked very cleanly removing and restoring visiblity to the panel once the form was displayed, but is still spotty on form load. I added the panel.visible=true at the very beginning of the Form_Load so I'll have to try it elsewhere to see if it improves the appearance, but you've now solved 2/3rds of my problem, at least!

Thanks again, Imar!

When you say "panel.visible=true", do you actually mean

panel.Visible = False?

I think you should set the panel's visibility to True at the end of form_load. That way, the form can do it's thing, change whatever you need to change, and then enable it at once.

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Providence by Godspeed you Black Emperor! (Track 3 from the album: F# A# Infinity) What's This?

No, I meant TRUE. I omitted that I set the default property to FALSE so that the panel is invisible when the form is first loaded. I then set Visible=true, assuming that the contents of the panel were instantiated at that point.

Haven't had a chance to try anything else since, but I'm also toying with the idea of making the panel visible, but placing it off screen at first so that it's not seen until I'm ready for it. Then maybe the flicker won't be an issue because it simply won't be on the form until I'm ready for it.

Unfortunately, placing the panel off screen until populated doesn't seem to make a difference. In fact, there doesn't even appear to be a difference once the panel has been painted once. I was in error when I suggested this in my previous post, because I think, the test I tried involved a lot less objects than my actual problem.

Anyway, I've given it some thought and don't think there's any way to make this faster. As I mentioned earlier, there's a marked difference between hiding the controls and making them visible. Hiding the panel occurs almost instantaneously and in one step, whereas adding it repaints each control in turn (in opposite order, in fact, from bottom to top) in the same way as occurs when the form is first loaded. I tried playing with the VS generated interface code a couple of different ways and nothign seemed to work.

My theory on this odd behavioral difference between the two states is that MS is taking advantage of the standard windows refresh rate to handle interface changes like this. When hiding the panel, .NET simply says don't paint these objects on the next hardware refresh. But when drawing them, .NET has to position and draw each one manually, that takes time, and MS has inserted a refresh between each one that I can't seem to override. And when the objects are already drawn, the refresh simply doesn't appear because the objects are already on the screen. I therefore believe this is another of those "can't be done" instances and the users will just have to live with the ugly form load.

On the plus side, though, containing the objects in a panel not only makes it much faster to hide the controls and also significantly reduced the amount of code involved, from 80 or so Visible=False statements to 1. The same was true of course with Visible = True. If nothing else, the processing time is marginally faster. On the downside, the stupid VS interface changed ALL the tabindexes when I had to cut and paste the objects from the form to the panel. This is about the 50th time I've had to change all the tabindexes and I'd sure like to see something that will do this more easily. I've noted that cutting and the repasting an object in the same form disconnects the object from all event code on the form, but didn't expect to have to change all my tabindexes as well. Hello, MicroSoft?!?!?!

I'd really suggest you go to the microsoft site for VB.NET and comment there.. I am sure there is a link there. Having worked with many MSFT people directly, I can tell you customer input IS valued and one person CAN make a difference in how a product is released...

Hal Levy
Web Developer, PDI Inc.

NOT a Wiley/Wrox Employee

Thanks for the suggestion, Hal. I tend to come here first because I've found I get more help from my fellow developers (Imar in particular) than from Microsoft when I run into problems like this. But it would be wise to let MS know, too, in the hopes that imporvements may be made over time.