Time
in [MFC]
|
From: vvf on 2 Apr 2010 07:15 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
From: AliR on 2 Apr 2010 08:44 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. "vvf" <vvf(a)vvf.com> wrote in message news:uXJdaXl0KHA.4548(a)TK2MSFTNGP06.phx.gbl... > 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 > > > >
From: Joseph M. Newcomer on 2 Apr 2010 11:08 See below... On Fri, 2 Apr 2010 14:15:01 +0300, "vvf" <vvf(a)vvf.com> wrote: >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). **** Yes, that is correct **** >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 ? **** No, because (a) your resolution is limited to integer multiples of the 15ms timer tick and (b) your control of the priority of the thread is insufficient to guarantee the emulation of MM 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... **** Yes, but the point is that you CAN'T manipulate the window safely from another thread, you don't understand the relationship of windows to threads, and you are assuming that there will be "interference", which has no real basis for belief. In fact, you are at the mercy of the GUI thread no matter what. What "interference" do you think is going to happen if the high-priority thread is putting message into the queue, and the UI thread is lower priority? How is the UI thread going to "interfere"? Note that mouse and keyboard messages could get ahead of you, but the are pretty trivial to process. **** >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. **** Then what's wrong wtih WM_TIMER? **** > 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. **** Then you have no choice. But note that 2 seconds is close to eternity, and any "interference" from other messages is going to require tiny amounts of time to process (unless you yourself have introduced lengthy computations into your main GUI thread, in which case not even the MM timer will help you!) You seem to be unduly concerned with what is probably a non-problem, unless you have a REALLY active PostMessage sequence which floods the input queue, and at that point your problems are much more serious than a dropped WM_TIMER message.; you will have to fix other problems first. You have hypothesized potential interference without justifying that this is going to be a real problem in your app. So either use the MM timer or use WM_TIMER messages. joe **** > >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 > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Pages: 1 Prev: MFC and JNI Next: Writing a huge file with MFC - is it possible |