mfc dialog application problem
-
pierre_ribery wrote:
Forget the timer approach. PostMessage is the correct way to do this.
Why? :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
Because you are not guaranteed that the WM_TIMER message will be handled. THe dialog might be closed before the timer elapses (lets say 200-300ms). If you post a user defined message in OnInitDialog you are guaranteed that it will be handled before any messages sent after this! the timer might be invoked too late. From MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue. also, you have to remember to kill the timer as the first thing in the WM_TIMER handler. Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources. Might be more reasons, but it boils down to what is the best approach. The timer approach is a possibility, but not the BEST.
-
Because you are not guaranteed that the WM_TIMER message will be handled. THe dialog might be closed before the timer elapses (lets say 200-300ms). If you post a user defined message in OnInitDialog you are guaranteed that it will be handled before any messages sent after this! the timer might be invoked too late. From MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue. also, you have to remember to kill the timer as the first thing in the WM_TIMER handler. Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources. Might be more reasons, but it boils down to what is the best approach. The timer approach is a possibility, but not the BEST.
pierre_ribery wrote:
THe dialog might be closed before the timer elapses (lets say 200-300ms).
Provided you know such a feature it may be not a problem.
pierre_ribery wrote:
also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Of course. one-shot has to be one-shot, after all!
pierre_ribery wrote:
The timer approach is a possibility, but not the BEST
pierre_ribery wrote:
rom MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
To both points applies: Provided you've to immediatly execute code. :)
pierre_ribery wrote:
Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Oh, there are two possibilities here: (1) You already have such a timer (for different purposes) and you're just using its first call (in such a case, no performance loss). (2) You haven't such a timer and hence make a one-shot timer that is a low resource waster.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
modified on Monday, December 17, 2007 5:11:51 AM
-
You can call
PostMessage()insideOnInitDialogto post a user message, then in the message handler do needed stuff. You can also use a one-shot timer for it. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
Thank you CPallini Does that message will be the first message that the application received after it showed on the desktop? :)
-
pierre_ribery wrote:
THe dialog might be closed before the timer elapses (lets say 200-300ms).
Provided you know such a feature it may be not a problem.
pierre_ribery wrote:
also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Of course. one-shot has to be one-shot, after all!
pierre_ribery wrote:
The timer approach is a possibility, but not the BEST
pierre_ribery wrote:
rom MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
To both points applies: Provided you've to immediatly execute code. :)
pierre_ribery wrote:
Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Oh, there are two possibilities here: (1) You already have such a timer (for different purposes) and you're just using its first call (in such a case, no performance loss). (2) You haven't such a timer and hence make a one-shot timer that is a low resource waster.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
modified on Monday, December 17, 2007 5:11:51 AM
Please re-read my post, I have made some updates.
-
This is a dialog based application. I want the application execute some code after the main window and all child windows displayed correctly. Where should I write the code ? I think OnInitDialog is not a good place, because the window have not displayed yet. Thank you all!
Thank you all! I found call PostMessage in the dialog's OnInitDialog member before it returned is a good solution, it woks well :)
-
Please re-read my post, I have made some updates.
-
pierre_ribery wrote:
THe dialog might be closed before the timer elapses (lets say 200-300ms).
Provided you know such a feature it may be not a problem.
pierre_ribery wrote:
also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Of course. one-shot has to be one-shot, after all!
pierre_ribery wrote:
The timer approach is a possibility, but not the BEST
pierre_ribery wrote:
rom MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
To both points applies: Provided you've to immediatly execute code. :)
pierre_ribery wrote:
Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Oh, there are two possibilities here: (1) You already have such a timer (for different purposes) and you're just using its first call (in such a case, no performance loss). (2) You haven't such a timer and hence make a one-shot timer that is a low resource waster.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
modified on Monday, December 17, 2007 5:11:51 AM
Why wait executing the code? The sooner the better I would think. That being said, you are wasting resources even if it is a one-shot timer. I think that any professional windows programmer would agree with me that the timer approach is not the best, but again you are free to do it the timer way if you think that is best.
-
Why wait executing the code? The sooner the better I would think. That being said, you are wasting resources even if it is a one-shot timer. I think that any professional windows programmer would agree with me that the timer approach is not the best, but again you are free to do it the timer way if you think that is best.
pierre_ribery wrote:
That being said, you are wasting resources even if it is a one-shot timer.
:-D
pierre_ribery wrote:
I think that any professional windows programmer would agree with me that the timer approach is not the best
It is just an alternative to me. Anyway, thank you for including me among the hobbysts :laugh:
pierre_ribery wrote:
you are free to do it the timer way if you think that is best.
Oh freedom, what a wonderful thing! :) Have a nice day :rose:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
pierre_ribery wrote:
That being said, you are wasting resources even if it is a one-shot timer.
:-D
pierre_ribery wrote:
I think that any professional windows programmer would agree with me that the timer approach is not the best
It is just an alternative to me. Anyway, thank you for including me among the hobbysts :laugh:
pierre_ribery wrote:
you are free to do it the timer way if you think that is best.
Oh freedom, what a wonderful thing! :) Have a nice day :rose:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
I agree that it is an alternative. But can you please answer this question: Which approach do you think is the best?
-
I agree that it is an alternative. But can you please answer this question: Which approach do you think is the best?
pierre_ribery wrote:
I agree that it is an alternative. But can you please answer this question: Which approach do you think is the best?
Yours (you're a professional, after all), of course. :-D just kidding. :rose:
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.