|
I didn't look at MFC internals, but consider this scenario:
Base *pBase = new Child;
Child *pChild = (Child*)pBase;
What does the pChild refer to? I think a child, not a parent. (I didn't test it yet)
Now take a look at this:
CWnd* pWnd = new CEdit;
...
...
CEdit* pEdit = (CEdit*)GetDlgItem(EDIT_BX);
CWnd* GetDlgItem(UINT blah)
{
return pWnd;
}
if they did something like this, we actually have a pointer to a child.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}
|
|
|
|
|
In your first scenario, you will have a pointer to a "real" Child object.
In the first part of your second second scenario, pWnd points to a "real" CEdit. In the second part, the underlying object that pEdit refers to depends on what GetDlgItem(...) returns. In your example, it returns the pointer to a real CEdit, although through a CWnd pointer, and it is safe to cast that returned pointer back to a CEdit, because it WAS a CEdit in the first place. In the MFC code, it is a little different as shown below.
The only scenario where it will return a real CEdit object is if one is already in the handle map associated with the EDIT_BX edit control. For example, if you associate a CEdit class with the control using ClassWizard, and you then have it as a data member, then when you call GetDlgItem(...) with that control's identifier, you will get back a pointer to the existing CEdit data member.
If not, meaning that the HWND of the window you are looking for is not already in the handle map, you get back a pointer to a CTempWnd, which never was (and never will be) a CEdit. Additionally, that CTempWnd instance gets destroyed the next time the message pump starts running, which is why the docs say that the returned pointer may be temporary and should not be stored.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: you get back a pointer to a CTempWnd
So bad. Thanks for the information. From now on, I'll avoid using GetDlgItem. What I see here is really a bad coding style, I think. Finding a window, creating a temp one, and destroying that, is not what I like to happen, when I just need to enable or disable(, etc.) it( Considering the fact that I try this for a lot of controls at the same time.)
Thank you, really informative.
-- modified at 13:32 Thursday 16th August, 2007
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}
|
|
|
|
|
Mark Salsbery wrote: If you've only constructed a Base object it can't be a derived object.
The only way to have a Derived object is to create a Derived object (or a class derived from Derived).
Downcast is OK.
Maxwell Chen
|
|
|
|
|
Of course it is - if the object is actually the type you're downcasting to 
It was not in the OP's example.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark, If the derived class does not define any data members then the structure is not changed and therefore the base class can "be" a derived class although you would have to use old style cast or reinterpret_cast as the others are intended to report this as an error. So not saying it's a good idea. Also in most cases the need to up-cast is indicative of a poor design. However when dealing with a library...
|
|
|
|
|
Fine. I guess "can't" was the wrong word.
IMO it's a really bad idea. It requires knowledge of the class one really shouldn't
need to have to know. Plus it makes future additions to the derived class
problematic.
Why would one derive a class and not add anything? Even a virtual function
override is going to add to the class.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: IMO it's a really bad idea.
Yes, as I stated. I have used it to deal with MFC issues in the past. I have never designed it into my own classes.
Mark Salsbery wrote: Why would one derive a class and not add anything? Even a virtual function
override is going to add to the class.
Notice that the virtual override does NOT work (goes to foo) making this a very tenuous situation, but under certain conditions...
class foo
{
int n;
public:
foo(int v){n=v;}
virtual void dump(){cout << "foo: " << n << endl; }
};
class bar : public foo
{
public:
virtual void dump(){cout << "bar: "; dump();}
void dumpex(){cout << "bar: "; dump();}
};
foo* f = new foo(12);
bar* mybar = reinterpret_cast<bar*>(f);
mybar->dump();
mybar->dumpex();
|
|
|
|
|
I'm not disagreeing at all. It just makes me cry a little inside
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: It just makes me cry a little inside
Nah, it's all good. I'm working on some C# I developed last week as we speak. I just noticed some Rube Goldberg stuff I wrote, did a   and quickly leveraged the delete key.
|
|
|
|
|
|
Mark Salsbery wrote: Why would one derive a class and not add anything?
Simple. The member functions change from derivation to derivation. In that case, the base class defines the common data, and the member functions in the derived classes define the behavior. You can cast a base class to a derived one to choose behavior.
Note that I'm not advocating doing things this way. This requires that the code 'knows' that the cast is safe. Also, this kind of goes in the reverse direction of the virtual mechanism, which could lead to all sorts of subtle bugs if you combined the two  .
Software Zen: delete this;
|
|
|
|
|
|
mark salsbery wrote: Why would one derive a class and not add anything?
I can't believe I asked that! LOL 
Still, the downcast kind of implies you need something in the derived class that's not in the base.
It seems like a bad idea, which is probably why RTTI returns NULL on the invalid downcast.
Cheers ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Guess I can't do things this way. I was sort of hoping that there would be default constructors for creating a new derived object with the base object, that would automatically do a hard copy of the data from the base object.
I knew beforehand that my dynamic_cast case would not work, though.
|
|
|
|
|
The only time what you are doing is 'safe' is when Base and Derived have exactly the same data members.
Software Zen: delete this;
|
|
|
|
|
how to create a bar in dialog base application, like how we create in SDI/MDI.
regards
sudhakar
|
|
|
|
|
You cannot just create it and set the dialog class as the parent? Example: http://www.codeproject.com/docking/display_dialog_tooltips.asp[^].
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
From my application I am opening a document (could be Word, pdf, anything) using ShellExecute(). Now how can I check whether:
(i) The document is still open.
(ii) Some unsaved changes are made to that document.
We can not watch a directory for changes because that will work only when changes are saved to documents or new documents are created.
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
PravinSingh wrote: (i) The document is still open.
You can't. You can, however, know if the application itself is still open.
PravinSingh wrote: (ii) Some unsaved changes are made to that document.
Not possible that I know of.
PravinSingh wrote: We can not watch a directory for changes because that will work only when changes are saved to documents or new documents are created.
So unless those changes are committed to disk, why worry about them?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: So unless those changes are committed to disk, why worry about them?
In my applicaltion I have a record with an attached document (which I am opening with ShellExecute). Before navigating away from this record, I want to warn the user of any unsaved changes in the attached document.
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
What are you trying to do, some sort of work-flow application? If so you are going about it the wrong way, operating on assumptions that are unfounded. Try doing some research on whatever problem you are trying to solve and see what knowledge the industry has that might be of help to you.
|
|
|
|
|
|
sudheee wrote: if its not working i am sorry.
You must be a manager
|
|
|
|
|
sudheee wrote: by tracking the position of the file pointer u can find whether the opened document have unsaved changes or not.
I'm going to give you the benefit of the doubt and assume you are kidding. Tracking whether a file has changed by looking at the file pointer is not even a remote possibility.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
