|
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.
|
|
|
|
|
Thanks toxcct,
What means per se?
toxcct wrote: per se
regards,
George
|
|
|
|
|
George_George wrote: What means per se?
it means "it is what it is".
look deeper in a dictionnary of your own language to get it.
|
|
|
|
|
Thanks for your confirmation, CPallini!
regards,
George
|
|
|
|
|
George_George wrote: 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.
yes, you could, but sincerely, you shouldn't.
is the accessor is constant, then don't enforce it. if you own the class (if you wrote it yourself), then write a second one without the const property.
const_cast<>() is really a bad operator AFAIK C++, because it can lead developpers to use it against the spirit the class used. if you must access a member, then the author of the class should think about such a possibility, and implement it.
|
|
|
|
|
Hi toxcct,
Any comments on my original question,
--------------------
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
|
|
|
|
|
1) i replied your original question : "yes, you could, but sincerely, you shouldn't".
2), your question wasn't clear enough to mean that you were talking about the this pointer.
the this pointer is just a pointer of the type of the class. example:
if you have a class T, then this is implicitely declared as :
class T {
private:
T* this;
public:
T& getReferenceThis() { return *this; }
const T& getReferenceThis() const { return *this; }
};
the point is, if you're returning it from a const accessor, then the accessor caller will not be allow to modify the returned object, but still the this pointer is not const per se.
|
|
|
|
|
Thanks for your clarification, toxcct!
regards,
George
|
|
|
|
|
toxcct wrote: const_cast<>() is really a bad operator AFAIK C++, because it can lead developpers to use it against the spirit the class used
Yes, I agree. I think it is only useful whenever you have to deal with bad written code that you cannot modify (e.g. Suppose you must use a DLL containing a function that accepts as argument a char * but it in fact don't write into the passed buffer).
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
