Control.Paint gone missing

[vooose]

Consider a UserControl TopCont that contains two other UserControls,
CompA and CompB.

Somewhere in the constructor of TopCont we have

CompA.Paint += new PaintEventHandl er(compA_Paint) ;
CompB.Paint += new PaintEventHandl er(compB_Paint) ;

I am calling Invalidate() on both of the child components and this
results in their respective paint methods executing. However at some
point when I call CompA.Invalidat e(), its painting method (compA_Paint)
is not being called. (this is what I am trying to figure out). I *never
*actively* do

CompA.Paint -= new PaintEventHandl er(compA_Paint) ;

so I'm wondering how this would occur? Also I am using the debugger to
step over the lines of code where I have observed this happening but I
don't ever see the Control.Paint when I inspect the component.
I guess my second question is how at a given breakpoint can you inspect
a control and see which method was += to the Paint event?
Wal
--

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tim Jarvis]

vooose wrote:

Consider a UserControl TopCont that contains two other UserControls,
CompA and CompB.

Somewhere in the constructor of TopCont we have

CompA.Paint += new PaintEventHandl er(compA_Paint) ;
CompB.Paint += new PaintEventHandl er(compB_Paint) ;

I am calling Invalidate() on both of the child components and this
results in their respective paint methods executing. However at some
point when I call CompA.Invalidat e(), its painting method
(compA_Paint) is not being called. (this is what I am trying to
figure out). I *never *actively* do

CompA.Paint -= new PaintEventHandl er(compA_Paint) ;

so I'm wondering how this would occur? Also I am using the debugger to
step over the lines of code where I have observed this happening but I
don't ever see the Control.Paint when I inspect the component.
I guess my second question is how at a given breakpoint can you
inspect a control and see which method was += to the Paint event?
Wal
--

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

ok, here is your first "is it plugged in" type question.

does the code that does the invalidate actually get called ? for
example if you are doing the invalidate in a property setter you may
find that the invalidate is not actually getting called. example....
public SomeComplexType MyComplexType
{
get
{
return _myPrivateCompl exType;
}
set
{
invalidate();
_myPrivateCompl exType;
}
}
later in your code somewhere

MyControl.MyCom plexType.Color = Colors.Blue;

this will not cause your setter to fire (and subsequently the
invalidate), because as far as your control is concerned the property
has not been changed only a sub property has changed so the private
field still contains the same object, in fact its the getter that has
fired.

I don't know if this is your problem, but it is a common issue.

Regards Tim.

[vooose]

Tim thanks for your reply.

In this case I can guarantee that Invalidate() on the troublesome
component. In fact, the first thing I did was add a method called
InvalidateCompA () which looks like:

public void InvalidateCompA ()
{
contA.Invalidat e();
}

and I put a breakpoint at this line, and it was hit. As explained before
I couldnt determine what Paint methods were going to get called as a
result of this Invalidate() because I don't know where this info is
hidden in the debugger!

Wal
--

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tim Jarvis]

vooose wrote:

Tim thanks for your reply.

In this case I can guarantee that Invalidate() on the troublesome
component. In fact, the first thing I did was add a method called
InvalidateCompA () which looks like:

public void InvalidateCompA ()
{
contA.Invalidat e();
}

and I put a breakpoint at this line, and it was hit. As explained
before I couldnt determine what Paint methods were going to get
called as a result of this Invalidate() because I don't know where
this info is hidden in the debugger!

Wal
--

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

No probs, just sorry it didn't help. I had a problem myself a couple
weeks ago and this was the issue.

do you have a small project that reproduces this problem ? Perhaps you
could post that up.

Regards Tim.

[vooose]

Unfortunately I can't develop a stable recreate. However knowing how to
determine the event handler for

control.Paint += <where is this at debug time>

is going to help solve this one, as this is the thing that goes missing.
Do you know how to print out the paint handlers at runtime?

Wal
--

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tim Jarvis]

is going to help solve this one, as this is the thing that goes
missing. Do you know how to print out the paint handlers at runtime?

you mean you want to know if it fires ?

you can use Debug.WriteLine , that will write to the output window, so
you can at least see if has fired. (the Debug class is in the
System.Diagnost ics assembly)

Regards Tim.