event disappearing

[Tim Jarvis]

Hi,

I have a really frustrating problem....

I have a custom windows form control that contains a collection of
controls, these controls in turn contain other controls, a titlebar for
example a client scrollable area etc. My component needs to be able to
generate a custom click (cardpanelclicked) event that has a custom
eventargs class that shows which control was clicked, and what area of
the control was clicked, so this means I need to have my contained
classes propogate up through the parent controls....with me so far ?

Now the thing is, this works fine if I step through the code in the
debugger, however when I run the app normally the event does not fire
or actually it may, it may just be the paint event getting lost, I
can't tell for sure as when I debug, it works as designed....I am doing
my head in on this, please help if you can !!!
Regards Tim.

PS in groping at straws mode I have tried a DoEvents() and also a
Thread.Sleep(100) as well, to no avail.

[Tim Jarvis]

Tim Jarvis wrote:

Hi,

I have a really frustrating problem....

I have a custom windows form control that contains a collection of
controls, these controls in turn contain other controls, a titlebar
for example a client scrollable area etc. My component needs to be
able to generate a custom click (cardpanelclicked) event that has a
custom eventargs class that shows which control was clicked, and what
area of the control was clicked, so this means I need to have my
contained classes propogate up through the parent controls....with me
so far ?

Now the thing is, this works fine if I step through the code in the
debugger, however when I run the app normally the event does not fire
or actually it may, it may just be the paint event getting lost, I
can't tell for sure as when I debug, it works as designed....I am
doing my head in on this, please help if you can !!!
Regards Tim.

PS in groping at straws mode I have tried a DoEvents() and also a
Thread.Sleep(100) as well, to no avail.

[Tim Anderson]

"Tim Jarvis" <Ti*******@newsgroup.nospam> wrote in message
news:ua**************@TK2MSFTNGP09.phx.gbl...

Now the thing is, this works fine if I step through the code in the
debugger, however when I run the app normally the event does not fire
or actually it may, it may just be the paint event getting lost, I
can't tell for sure as when I debug, it works as designed

Debug.WriteLine is handy for debugging this kind of problem.

Tim
..NET pros and cons
http://www.itwriting.com/phorum/list.php?f=6

[Kevin Yu [MSFT]]

Hi Tim,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that the custom event was not fired when the
app is running in release mode. However, in debug mode, it works fine. If
there is any misunderstanding, please feel free to let me know.

If it fires in debug mode, I think it has to be fired also in release mode.
Could you please post some of your code here for an example, so that I can
try to repro it on my machine? It will be more quickly for us to deliver
our assistance with some source code. Thanks!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Tim Jarvis]

Kevin Yu [MSFT] wrote:

Hi Tim,

First of all, I would like to confirm my understanding of your issue.
From your description, I understand that the custom event was not
fired when the app is running in release mode. However, in debug
mode, it works fine. If there is any misunderstanding, please feel
free to let me know.

If it fires in debug mode, I think it has to be fired also in release
mode. Could you please post some of your code here for an example,
so that I can try to repro it on my machine? It will be more quickly
for us to deliver our assistance with some source code. Thanks!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Hi Kevin,

Nope, that's not it. I have not tried it in release mode, it is that
the event does not fire when the app is run normally (or in the IDE)
but does fire when stepping through the code in the debugger.

In fact further investigation tells me that it is in fact just the
paint message that is being lost, I do indeed have several
debug.writeline messages ( thanks for the suggestion Tim A, but had
already done that) and that is writing a debug message in the custom
event, however at the end of the event handling code I invalidate the
control to repaint, its this that is being eaten, however when stepping
through the code, on resumption the paint works fine.

The code is part of a very large project with tendrils that run very
deep and connect to an OPF, to extract the control will be very time
consuming (probably a day or so, conservatively)....which I might have
to resort to, but if you can help without it in the first instance that
would be fab.

Regards Tim.

[Tim Jarvis]

Tim Anderson wrote:

Debug.WriteLine is handy for debugging this kind of problem.

Thanks Tim,

Yeah have several of them, actually they do print, so the event is
firing, my wording of my question was poor...Its the paint message that
is being eaten, the final event handler in the chain does some stuff
and then invalidates the control for a repaint, its this that is not
happening. (and as you probably know, in a custom control the meat and
potatoes is in the paint)

The weird thing is this does paint correctly after a break, and step
through the code, just not without a break.

Cheers Tim.

[Tim Anderson]

"Tim Jarvis" <Ti*******@newsgroup.nospam> wrote in message
news:u8**************@TK2MSFTNGP09.phx.gbl...

Tim Anderson wrote:
Its the paint message that
is being eaten, the final event handler in the chain does some stuff
and then invalidates the control for a repaint, its this that is not
happening. (and as you probably know, in a custom control the meat and
potatoes is in the paint)

There are some flags that determine how a control paints. Have a look at the
help entry for the ControlStyles enumeration. Is it possible that a
different setting could fix the issue? These are normally set in the
constructor.

Tim
IE share declining - does it make a difference?
http://www.itwriting.com/blog/?postid=106

[Kevin Yu [MSFT]]

Hi Tim,

Besides Tim A's advice, I think you can also check the watch window. Some
methods might be called in it which makes the event firing working properly
when debugger stops on some breakpoints. Believe me, it's quite hard to
debug on this kind of problem without seeing a repro.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Tim Jarvis]

Kevin Yu [MSFT] wrote:

Hi Tim,

Besides Tim A's advice, I think you can also check the watch window.
Some methods might be called in it which makes the event firing
working properly when debugger stops on some breakpoints. Believe me,
it's quite hard to debug on this kind of problem without seeing a
repro.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Yeah I know, this is the worst kind of issue to have, when the act of
debugging changes the outcome (In this case makes the problem go away)

I will see if its possible to create a test case that duplicates the
problem and post it up.
Cheers Tim

[Tim Jarvis]

Tim Anderson wrote:

There are some flags that determine how a control paints. Have a look
at the help entry for the ControlStyles enumeration. Is it possible
that a different setting could fix the issue? These are normally set
in the constructor.

Thanks Tim, yeah I know about those, I am am in fact using double
buffering, so have set some flags i.e. userpaint, double buffer and
allpaintinginwmpaint, I also have set the repaint on resize flag as
well. And of course one of the first things I looked at was those
flags, sadly that is not the issue.

the stucture of the control is a container type contol that contains a
collection of panels, these panels in turn contain a collection of
categorys which are just panels them selves except they are scrollable,
the panels all contain a title bar as well, so you are probaly getting
the picture controls in controls in controls, and what I need to do to
produce a click event in the top level control is pass it up the chain
about 3 levels, and it seems to work fine, just loses the paint at the
end......very frustrating.

Kevin has asked for a test case that reproduces the problem, which is
entirely reasonable (that's what I ask for when it's me on that side of
the fence) I am going to try and do that in the morning.

Cheers Tim.

[Kevin Yu [MSFT]]

Thanks for your cooperation, Tim. Could you also check if this happens on
another machine if you copy all the project files to it?

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Tim Jarvis]

Kevin Yu [MSFT] wrote:

Thanks for your cooperation, Tim. Could you also check if this
happens on another machine if you copy all the project files to it?

Hi Kevin,

I have resolved the issue. In the process of creating a test case I
found a workround.

The issue is I was modifying a subproperty, this subproperty, modifies
an internal value that is used in the painting, in this case a gradient
start color and a gradient end color (in another case a position within
the container), now what seems to be happening is that because the
properties sub property is modified a subsequent invalidate must think
there is nothing to do.

i.e. ....some stuff....

TitleColor.StartColor = Color.White;
TitleColor.EndColor = Color.DodgerBlue;
......some more stuff....
Invalidate();

does not repaint.

My workround was....

GradientColor grCol = new GradientColor(Color.White,Color.DodgerBlue);
TitleColor = grCol;

Now the invalidate works.

(note GradientColor is my own custom helper glass, that just holds the
start and end colors the gradient mode, and generates a gradient brush
for me)

Now I don't know if this is a GDI+ bug or designed behaviour, I can
certainly see that an invalidate should only fire if required, however
this is an issue if as in my case its easily fooled...

Anyway, thanks for your help, its much appreciated. I hope that this
workround helps someone else in the same predicament.

Regards Tim.