Delayed displaying of a form?

  • Thread starter Thread starter Jesper
  • Start date Start date
J

Jesper

Is there any way to delay initial displaying a form until all controls have
finished painting?

I find it rather annoying that I can actually see the some controls popping
up before the form has done drawing, as well as seeing scrollbars before the
associated control. This is ofcourse particularly bad on slower computers
and in cases where some controls are displaying lots of data (my grids and
trees).

I had considered something like setting the form visibility to false in
OnLoad, and then setting it true in Form.OnPaint, but unfortunately both
OnLoad and Form.OnPaint comes before each of the child controls' OnPaint. I
cant seem to find any event that fires after all control have been painted.
 
It's amazing the improvement you get if you simply include an
Application.DoEvents() in the first activation of the form.
 
policywatcher said:
It's amazing the improvement you get if you simply include an
Application.DoEvents() in the first activation of the form.
Click to expand...

Reducing the number of controls to < 50 will help too ;-).
 
Yes, though I have seen problems with even quite few controls if the
processing of the first activation takes significant time - eg the loading of
data etc. Putting an application.DoEvents early in the first activation
seems to make it run smoothly in a number of such situations besides just
large forms.
 
The problem is almost non-existent if I just use standard controls like
labels, combos, etc. But unfortunately I have databound grids on most of my
forms, which are rather heavy visually and datawise. Just putting an
Application.DoEvents() doesnt help me (I tried). Neither does playing with
the visibility, the location, or the windowstate. The problem is not the
messagequeue. The problem is that the time from Form.OnPaint has done
painting until the last child control has done painting is too long. And in
this timeperiod (1-2 seconds) you can see the form base, the borders, maybe
some of the controls, and then transparent rectangular 'holes' where you are
actually viewing contents of whatever window is under it (z-wise), until
those controls have done painting.

I can now reduce the problem somewhat by moving all the databinding from
OnLoad to a userfunction and then putting "Application.DoEvents();
OnBindAll();" in the activation, so that I atleast get to paint the empty
control relatively fast, and then wait a bit to fill up the data, but it is
still not quite what I want.

Of course this is not a problem that breaks the application, but it does
make it look a bit like a hack and not a professional application that I
expect my customers to pay for. I never had any problems like this in my
previous version which was a classic MFC app.

I was hoping there was some way to paint to a buffer like "memory device
contexts" in MFC and then swapping the result into the visual context, which
gives a perfect instant drawing. This is what is usually done when you need
'flicker-free' animations (or just bitmap replacements) in MFC, so I figured
that there would have to be something like that in the .Net framework as
well if they want to allow any sorts of animation.
 
Ah...

In your form, create a function, say Init(), and put a call to OnBindAll()
in it.

The open the " Windows Form Designer Generated Code ", and after

'Add any initialization after the InitializeComponent() call

insert a call to Init()

[Yes, you could call OnBindAll() directly here, but I prefer all application
code to be in a section that is not routinely closed]

And KEEP the Application.DoEvents() in the OnLoad event.

In that way, the datagrid is bound and filled before the OnLoad event fires,
and the DoEvents continues to make the paint a tad smoother.

In some [simple] cases, I've actually been able to get it smooth simply by
doing the equivalent of the OnBindAll BEFORE the DoEvents rather than after,
but this solution generally is better, PROVIDED that any necessary external
initialisation data is present and stable during the actual form creation,
rather than only at OnLoad time.
 
Jesper,

If a large amount of data being loaded is your problem, you should probably
be loading the data on a worker thread.

Regards
Joubert
 
Although that will tend to exacerbate the problem of the controls all showing
blank and then re-showing with the data filled in, that Jesper was seeking to
avoid.

And all synchronization workarounds for that, will tend to have the form's
main thread waiting for the data to be stable, largely negating the benefits
of a separate thread.


Joubert said:
Jesper,

If a large amount of data being loaded is your problem, you should probably
be loading the data on a worker thread.

Regards
Joubert
Click to expand...
 
Back
Top