Time

[vvf]

Hi All,

I would like to use the multimedia timer in my MFC application in order to
update a certain area of my UI. From what I understand, a multimedia timer
is implemented basically using a high priority thread. In this case, is it
ok to interact with UI elements via a pointer to my dialog class from inside
the call back function ? This shouldn't be OK if the call back function runs
in some other (worker) thread. I would assume that I would have to post a
message and manipulate the UI from that message's handler (handled in the UI
thread) rather than in the callback function itself (located inside the
timer's thread). However, if this is the case, would I then be able to
forget all about the multimedia timer idea and just implement a high
priority worker thread that would from time to time post a message to my
window ? Would that "emulate" the behavior of a multimedia timer ? It just
seems that the "weak" link in all this is that I have to post a message and
the message could be backed up by other messages that the windows processes
therefore defeating the whole purpose of the timer... I don't really need a
high precision timer, all I want to do is "animate" something on the screen
by displaying various pictures representing the various frames of the
animation. I would like to rely on this timer in the sense that it would be
able to fire .. let's say, every 2 seconds, so it needs to be independent of
anything else that is going on (independent of how many messages are in the
message pump, etc). That's one of the reasons I don't like the idea of using
the WM_TIMER message.

Thanks in advance.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4991 (20100401) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[AliR]

You are always at the mercy of the message pump in an event driven
environment.

When you envolve a thread and a window, the rigth thing to do is post a
message to the window. Although nothing really pervents you from
manipulating the window from the worker thread. But then again when it
comes to animating, you will need to set up the frame and then force a
WM_PAINT, because if you are not drawing your window content in WM_PAINT
then you are not really drawing much, any moment windows can send your app a
WM_PAINT message and it will erase everything that you have done outside of
WM_PAINT. So at least 2 messages are involved here (WM_ERASEBKGND and
WM_PAINT).

Under normal circumstances I would say a 2 second timer would be fine with
WM_TIMER. Would you really care if it came at 2.01 seconds.

Maybe DirectX is the answer to your question.

AliR.

Post by vvf
Hi All,
I would like to use the multimedia timer in my MFC application in order to
update a certain area of my UI. From what I understand, a multimedia timer
is implemented basically using a high priority thread. In this case, is it
ok to interact with UI elements via a pointer to my dialog class from
inside the call back function ? This shouldn't be OK if the call back
function runs in some other (worker) thread. I would assume that I would
have to post a message and manipulate the UI from that message's handler
(handled in the UI thread) rather than in the callback function itself
(located inside the timer's thread). However, if this is the case, would I
then be able to forget all about the multimedia timer idea and just
implement a high priority worker thread that would from time to time post
a message to my window ? Would that "emulate" the behavior of a multimedia
timer ? It just seems that the "weak" link in all this is that I have to
post a message and the message could be backed up by other messages that
the windows processes therefore defeating the whole purpose of the
timer... I don't really need a high precision timer, all I want to do is
"animate" something on the screen by displaying various pictures
representing the various frames of the animation. I would like to rely on
this timer in the sense that it would be able to fire .. let's say, every
2 seconds, so it needs to be independent of anything else that is going on
(independent of how many messages are in the message pump, etc). That's
one of the reasons I don't like the idea of using the WM_TIMER message.
Thanks in advance.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4991 (20100401) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com