Re: Delayed displaying of a form?
From: Joubert (j_at_j)
Date: 11/11/04
- Next message: Jeffrey Tan[MSFT]: "RE: TreeView - Only Some Checkboxes"
- Previous message: Joubert: "Re: Does anyone actually use data binding in real life?"
- In reply to: Jesper: "Re: Delayed displaying of a form?"
- Next in thread: policywatcher: "Re: Delayed displaying of a form?"
- Reply: policywatcher: "Re: Delayed displaying of a form?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 11 Nov 2004 10:41:24 +0200
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
"Jesper" <no@spam.com> wrote in message
news:uKEZ80lwEHA.3276@TK2MSFTNGP15.phx.gbl...
> 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.
>
>
>
> "policywatcher" <policywatcher@discussions.microsoft.com> wrote in message
> news:771B512E-BAA7-41AE-AED5-77F7E5499707@microsoft.com...
>> 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.
>>
>> "Herfried K. Wagner [MVP]" wrote:
>>
>>> "policywatcher" <policywatcher@discussions.microsoft.com> wrote:
>>> > It's amazing the improvement you get if you simply include an
>>> > Application.DoEvents() in the first activation of the form.
>>>
>>> Reducing the number of controls to < 50 will help too ;-).
>>>
>>> --
>>> Herfried K. Wagner [MVP]
>>> <URL:http://dotnet.mvps.org/>
>>>
>
>
- Next message: Jeffrey Tan[MSFT]: "RE: TreeView - Only Some Checkboxes"
- Previous message: Joubert: "Re: Does anyone actually use data binding in real life?"
- In reply to: Jesper: "Re: Delayed displaying of a form?"
- Next in thread: policywatcher: "Re: Delayed displaying of a form?"
- Reply: policywatcher: "Re: Delayed displaying of a form?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|