|
You may be able to prevent this problem by passing less data with each call, passing references instead, keeping your data in a heap allocated structure etc. These changes may be simpler than changing the algorithm. If you post a few more details, function signatures, some idea of the data structures involved as solution may present itself.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi Everyone,
I need some help regarding implementation of iLBC codec for compressing audio files.
Thanks in advance..
regards,
programmer81
|
|
|
|
|
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!
|
|
|
|
|
You can call PostMessage() inside OnInitDialog to 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.
|
|
|
|
|
Go for the PostMessage approach. Post it at the end of OnInitDialog.
Forget the timer approach. PostMessage is the correct way to do this.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Thank you, I've just update mine 
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.
|
|
|
|
|
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.
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 
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 | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
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?
|
|
|
|
|
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.
just kidding.
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?
|
|
|
|
|
You are not totally right. The constructor is not a good place because the window is not created yet and you will get assertions. The OnInitDialog is called in the very moment when the window and all its controls where created and are going to be shown. If you modify contents, properties and so on of the controls and/or the dialog itself. It should give you no problems.
The window have not been displayed yet, but is the moment where it is being displayed, so all elements and relationships are already there.
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Thank you all!
I found call PostMessage in the dialog's OnInitDialog member before it returned is a good solution, it woks well
|
|
|
|
|
What is the code to detect when the user click the minimize icon and the close icon on the top right corner?
Like, when the user clicks the minimize icon, I may want make it a tray icon. when the user clicks the close icon, I may want make it a tray icon too, or exit the application and do some cleanup.
|
|
|
|
|
Handle the WM_SYSCOMMAND message. when the window is minimized, you will get the WM_SYSCOMMAND message with wParam as SC_MINIMIZE.
|
|
|
|
|
Hello everyone,
In MSDN sample for const_cast,
http://msdn2.microsoft.com/en-us/library/bz6at95h(VS.80).aspx
There is a statement like this,
--------------------
On the line containing the const_cast, the data type of the this pointer is const CCTest *. The const_cast operator changes the data type of the this pointer to CCTest *
--------------------
I think in a const member function, like void printNumber() const, the type of this pointer is const pointer to current type, so we use this const_cast to remove its const properties.
For a non-const member function, I think this pointer should not be a const pointer, right?
So, conclusion is,
1. in const member function, this pointer is a const pointer;
2. in non-const member function, this pointer is a non-const pointer.
Right?
thanks in advance,
George
|
|
|
|
|
Yes, because const member functions are not allowed to change (owning class) object state.
BTW: never do what that weird sample code does.
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.
|
|
|
|
|
Thanks CPallini,
I think is const member function, this is a pointer to const, and in a non-const member function, this is a normal pointer (not pointer to const). Right?
regards,
George
|
|
|
|
|
Yes.
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.
|
|
|
|
|
CPallini wrote: Yes
no 
it's not the this pointer that is modified to be (or not to be) const. the compiler just know that a function that call a const member function is not allowed to modify the object returned, but still the this pointer is not const per se.
|
|
|
|
|
You're right, but on practical grounds you've to consider it a pointer to a const object unless you want receive compilers errors.
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
