By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,342 Members | 1,193 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,342 IT Pros & Developers. It's quick & easy.

Windows.Forms.Timer does not fire

P: n/a
Hello NG,

in my application I have a Panel, docked right to my Form. On this panel I
draw - cyclic triggered by a System.Winforms.Timer - a bitmap using the
Graphics class.
using (Graphics g = pnlDisplay.CreateGraphics())
{
g.DrawImage(myBitmap, 0, 0);
}

On the left side of my main window, I have some other panels, a
DataGridView, and a TabControl and a Splitter, between those controls and my
"Display Panel".

If I now change the size of my Window in the running application, the
"Display" keeps its size , while the Bitmap loaded to it shows the dynamicly
changing graphic an the other controls left to the splitter move out of the
window.

So far so good, but if the window reaches a size, where the other Controls,
left to the "Display", are no longer shown, the "DisplayTimer" no longer
fires, and my dynamic graphic freeses. I have set a breakpoint to the timer
event handler, that is why I know, that it does not get fired any more.

My Question: What is causing this odd behavior, and what can I do about it?

Regards
Rainer Queck
Nov 18 '08 #1
Share this Question
Share on Google+
8 Replies

P: n/a
On Tue, 18 Nov 2008 02:56:18 -0800, Rainer Queck <Ra****@newsgroup.nospam>
wrote:
[...]
So far so good, but if the window reaches a size, where the other
Controls,
left to the "Display", are no longer shown, the "DisplayTimer" no longer
fires, and my dynamic graphic freeses. I have set a breakpoint to the
timer
event handler, that is why I know, that it does not get fired any more.

My Question: What is causing this odd behavior, and what can I do about
it?
I don't know. For your best chances of having the question answered, you
should post a concise-but-complete code sample that reliably demonstrates
the problem. For sure, the System.Windows.Forms.Timer class would
normally work under the scenario you describe.

But the main reason I'm replying is to suggest that you fix your program
so that you're not drawing in response to the timer. You should _only_
draw in an OnPaint() method or in a Paint event handler. If you want a
"dynamically changing graphic", then you should update the data used to
draw, and use the timer to decide when to call Control.Invalidate() to
cause the control instance to be redrawn via OnPaint()/Paint.

Your current technique is both inefficient and broken. It's inefficient
because you are drawing outside the normal process used by Windows, and
it's broken because if a redraw is caused by some other reason
(overlapping windows moving, for example) the graphics you've drawn will
be erased.

Pete
Nov 18 '08 #2

P: n/a
Hi Peter,

thanks for responding to my question.
I don't know. For your best chances of having the question answered, you
should post a concise-but-complete code sample that reliably demonstrates
the problem.
My application is in the meanwhile too complex to do this "in a minute or
two" and I hestitate to build a separate slim application to reproduce the
Probelm because:
- I have very little time
- I have done this on on or the other issue before, went into a discussion
in the NG with out result, and the issue was gone
with the next release of VS.
But the main reason I'm replying is to suggest that you fix your program
so that you're not drawing in response to the timer. You should _only_
draw in an OnPaint() method or in a Paint event handler. If you want a
"dynamically changing graphic", then you should update the data used to
draw, and use the timer to decide when to call Control.Invalidate() to
cause the control instance to be redrawn via OnPaint()/Paint.
Basically I agree to this. Actually I am handling it this way just vica
versa ;-)
My OnPaint event handler calls the timer handler.
This avoids your objection:
it's broken because if a redraw is caused by some other reason
(overlapping windows moving, for example) the graphics you've drawn will
be erased.
Regards
Rainer
Nov 18 '08 #3

P: n/a
Hello Peter,

rethinking your arguments:
But the main reason I'm replying is to suggest that you fix your program
so that you're not drawing in response to the timer. You should _only_
draw in an OnPaint() method or in a Paint event handler. If you want a
"dynamically changing graphic", then you should update the data used to
draw, and use the timer to decide when to call Control.Invalidate() to
cause the control instance to be redrawn via OnPaint()/Paint.
I changed my sequence of handling the drawing. Now my timer eventhandler
calls invalidate and the paint event handler does the drawing. Makes more
sense, you are right.

To my problem with the not fireing timer event, I forgot to mention a
important fact.
I only have the problem, if the TransparencyKey of the Form is set to a
Color.
Else the timer fires fine!

Regards
Rainer
Nov 18 '08 #4

P: n/a
On Tue, 18 Nov 2008 04:08:12 -0800, Rainer Queck <Ra****@newsgroup.nospam>
wrote:
[...]
To my problem with the not fireing timer event, I forgot to mention a
important fact.
I only have the problem, if the TransparencyKey of the Form is set to a
Color.
Yes, I'd call that an important piece of information. :)

Still, you are in the best position to create a piece of code that
reliably reproduces the problem. Based on your first-hand information
about what your code looks like, you should be able to write a very small
Forms application that starts up already in the visual state that prevents
the timer event from being raised.

Assuming your description of the problem is accurate, it may well be that
the best we can do is advise you to report the behavior as a bug. But
even for you to do that, you will need to have a concise-but-complete code
example that reliably demonstrates the problem. So one way or the other,
as much of a hardship as it might seem to you, if you care about the
problem this really is the best way through the problem.

You can wait and hope that the behavior is in fact a bug and that
Microsoft will somehow figure out that it's happening without your report,
but that's probably not the most reliable way to deal with the issue. :)

Pete
Nov 18 '08 #5

P: n/a
Hello Rainer,

Thank you for using Microsoft Managed Newsgroup, I'm Zhi-Xin Ye, it's my
pleasure to work with you on this issue.

Would you please send me a concise-but-complete code sample to reproduce
this problem? It will help me get a more concrete idea as to what the exact
problem is and how to resolve it efficiently. My email is
v-****@microsoft.com.

I look forward to your reply.

Sincerely,
Zhi-Xin Ye
Microsoft Managed Newsgroup Support Team

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subs.../aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 19 '08 #6

P: n/a
Hello Zhi-Xin,

I managed to reproduce the problem in a separat little application you
which I sent to you by e-mail.

On my efforts to reproduce the problem in a separat application, I
realized that the "Timer does not fire" issue seams to depend on two
factors:

- TabControl.
- TransparencyKey assinged

You should see the issue, if you smaller the witdh of the running
application moving the right border of the form to the left.
As soon as the left part with the TabControl disapears, the timer
"tmrPaint" does not get fired any more.

I hope this helps you to locate the reason.
Regards
Rainer
Nov 19 '08 #7

P: n/a
Hello Rainer,

I've received your sample code, and able to reproduce the problem. However,
I find a way to make the timer running all the time, i.e. use a
SplitContainer control instead. Put the panel2 and TabControl on the left
panel of the SplitContainer, and put the pnlDisplay on the right. You can
also set the SplitContainer.Panel1MinSize property to 0 to make the left
panel disappear when resizing.

I add a new form named "form2" in the sample code to demonstrate what I
said, you can run the code to see the result.

Please let me know if you have any questions or concerns.

Have a great day!

Best Regards,
Zhi-Xin Ye
Microsoft Managed Newsgroup Support Team

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

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

Nov 20 '08 #8

P: n/a
Hello Zhi-Xin,

thank you very much for your help!
With your workaround the Windows.Forms.Timers are firing again.

Regards
Rainer
Nov 20 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.