Checking if an event is being handled
-
I've got an app that does heavy background processing off a user adjustable timer. If the tick rate is pushed too fast and all the CPU capacity is hogged by the background activity, or the app's running near the limit and annother process starts eating heavy cycles my app stops behaving well. The most prominant issue is that the form doesn't handle the OnPaint event. Is there an easy way to test that the event is being handled so that I can throttle the timer.
-
I've got an app that does heavy background processing off a user adjustable timer. If the tick rate is pushed too fast and all the CPU capacity is hogged by the background activity, or the app's running near the limit and annother process starts eating heavy cycles my app stops behaving well. The most prominant issue is that the form doesn't handle the OnPaint event. Is there an easy way to test that the event is being handled so that I can throttle the timer.
In source code, you can check by comparing that event against null. If the event is equal to null, it means corresponding event is not being handled. Otherwise, it is being handled.
-
In source code, you can check by comparing that event against null. If the event is equal to null, it means corresponding event is not being handled. Otherwise, it is being handled.
You misunderstand what I need. The default event handler for OnPaint is installed, but if the other stuff my app does in the background is being called to rapidly the event handler never actually gets called. I'm using a high precision win32 timer that IIUC uses a high priority kernal thread to repeatedly check a high precision clock and fire events to my app. If it's set too rapidly (and too rapid depends on the cpu speed and it's background process load), the timer itself can consume 100% of my app's cpu time, and my apps OnPaint event handler stops being executed.
-
You misunderstand what I need. The default event handler for OnPaint is installed, but if the other stuff my app does in the background is being called to rapidly the event handler never actually gets called. I'm using a high precision win32 timer that IIUC uses a high priority kernal thread to repeatedly check a high precision clock and fire events to my app. If it's set too rapidly (and too rapid depends on the cpu speed and it's background process load), the timer itself can consume 100% of my app's cpu time, and my apps OnPaint event handler stops being executed.
I might get you wrong, too, but why don't you just add your own method to the event handler, which for example saves the time when it was executed in a variable, that you can check in your code. You might also override the OnPaint method of your form to do the above procedure:
protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) { lasttimeexecuted = DateTime.Now; base.OnPaint(e); }
-- modified at 12:21 Wednesday 7th June, 2006 -
I might get you wrong, too, but why don't you just add your own method to the event handler, which for example saves the time when it was executed in a variable, that you can check in your code. You might also override the OnPaint method of your form to do the above procedure:
protected override void OnPaint(System.Windows.Forms.PaintEventArgs e) { lasttimeexecuted = DateTime.Now; base.OnPaint(e); }
-- modified at 12:21 Wednesday 7th June, 20063Dizard wrote:
I might get you wrong, too, but why don't you just add your own method to the event handler, which for example saves the time when it was executed in a variable, that you can check in your code.
That sounds like it should work. Apparently my brain's been thinking it's friday 4:30pm all day. :doh::doh: