dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pnet-developers] Controls: when to create a handle ?


From: Marc Haisenko
Subject: Re: [Pnet-developers] Controls: when to create a handle ?
Date: Fri, 11 Feb 2005 18:47:11 +0100
User-agent: KMail/1.7.1

On Friday 11 February 2005 17:43, Neil Cawse wrote:
> > Hi folks,
> > I'm currently hunting another layouting bug in Control.cs. After more
>
> than
>
> > a day I've finally found the cause: PerformLayout immediateley returns
> > when no handle (toolkitWindow) was created.
> >
> > So my question is: when should a handle be created ?
>
> This is a bit rusty in my mind but we always try defer creating the
> handle until we have to. The reason for this is that once the handle is
> created, we have to then send all characteristic changes of the control
> through to the underlying operating system window. This makes
> performance poor.

I really get crazy fixing this bug I'm seeing... I'm digging through the 
Form.cs, Control.cs and Toolkit code for about three (working)days now. 
Problem is, if I remove the check for toolkitWindow being null in 
PerformLayout my bug is fixed, but almost everything else is then broken ;-)

If I create the handle earlier then the (not fixed) bug #10396 shows again 
(TopLevel property only has an effect if it is set before the handle is 
created !). I've tried to fix THAT one but I'm totally lost here, it seems 
like it's not possible to change the toolkitWindow once it has been set up as 
very strange things happen if I do.

Oh dear, and I'm currently so confused and my mind is so twisted by all this 
stuff that I'm really not able to explain it here :-((( Maybe I'll write a 
looooong email on Monday explaining the bug and how I've tried to fix it.

> We only have to create the handle when CreateHandle() is called or the
> control itself becomes visible. If we are finding problems just because
> the handle isn't created, we need to redo that path of the logic.
>
> When the operating system receives from us, for example a size change
> command, it then calls back to us the "size change" event. We then have
> various layout logic that happens through this code path. This is where
> things fall down because if the handle is not created, that logic is not
> being called and still needs to happen.
>
> The slow part is not our internal layout logic but rather the slowness
> comes in from dealing with windows that are already created - so I would
> add checks into things like SetBoundsCore(..) and call the necessary
> code even when the handle is not created.
>
> You need to do a little testing to make sure that you are in fact
> creating the handle as late as possible - you will see a big performance
> hit if we regress and create the handles too early.
>
> Hope this helps.
>
> Regards
> Neil

Well, not really, but thanks for explaining this stuff to me anyways :-) I 
really need a break from this code and restart thinking about everything on 
Monday with a clean mind.

C'ya,
        Marc

-- 
Marc Haisenko
http://darkdust.net
Today is Boomtime, the 42nd day of Chaos in the YOLD 3171

Attachment: pgp0VVUt7958j.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]