|
I subclassed a control (actually, a CStatic) and want to access from it's functions some data members of the parent.
Let's say the new class of the control is CMyOwnCtl, and the parent, the main dialog, is CMyOwnDlg.
I am defining a pointer to the parent in CMyOwnCtl.h:
CMyOwnDlg *Parent;
This works only with
#include "CMyOwnDlg.h"
#include "CMyOwnCtl.h"
in this sequence. However, CMyOwnDlg.h requires the definition of CMyOwnCtl, i.e. the includes have to be in the other sequence.
I solved this by placing the pointer to the parent in the global definitions. However, I wonder if it could be done more elegantly.
|
|
|
|
|
You can put the includes in the cpp files, and then forward declare the class - so put
class CMyOnwCtl;
in the top of CMyOwnDlg.h and vice versa. This tells the compiler that a class exists, and it will find the details out during the compile process.
I should add - this works because you have a *pointer* to CMyOwnDlg in CMyOwnCtl - this is fine, all the compiler needs to do when compiling the header, is allocate space for a pointer. If you put an instance of the object in the header, it would not work.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I tried this already before asking, but it causes an error, when assigning the address of the parent to the pointer. If ctl_MyControl is the member variable of the instance of the subclassed control, and Parent is defined in MyOwnCtl.h as
class Parent;
then
ctl_MyControl.Parent = this;
in the parent's OnInitDialog causes
error C2440: '=' : cannot convert from 'class CMyOwnDlg *const ' to 'class $S217 *'
However, if the pointer is defined (in the globals) as
CMyOwnDlg *Parent;
then
Parent = this;
works fine from OnInitDialog.
|
|
|
|
|
Vancouver wrote: ctl_MyControl.Parent = this;
This means that ctl_MyControl is not a pointer, which means it won't work, like I said. If ctl_MyControl is a member variable, a forward declaration will only work if it's a pointer to an instance of your control.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Sorry, I mistyped it in the post. Of course I declared it as a pointer and it created the mentioned error.
|
|
|
|
|
|
class *Parent;
is in CMyOwnCtl.h. If it was not there, I would not have any problem: in the function itself CMyOwnDlg can be used. because both headers are known there (and then John M. Drescher's suggestion works).
|
|
|
|
|
When you use forward declaration. The forward declared variable cannot be accessed in the declaration file, since compiler only knows the pointer and allocates the size of pointer when you access it, compiler won't have enough information to do this.
ctl_MyControl.Parent = this;
Is this statement is in declaration file, if so, use this in a function definition is cpp file.
Since the dialog is immediate parent, you know the level of the parent class, you can use john's method (dynamic cast the parent window).
Best Regards
Raj
|
|
|
|
|
One thing you could do is to make *Parent a class member of CMyOwnCtl and pass it in a constructor or a SetParent member.
Actually you do not need to store the pointer though as you can always do a GetParent() in the control and DYNAMIC_CAST or (dynamic_cast) the CWnd pointer to CMyOwnDlg. I do this 90% of the time and use dynamic_cast syntax over DYNAMIC_CAST as my programs are compiled with RTTI and I avoid the MFC macros as much as I can.
John
|
|
|
|
|
This appeared to be all right, at least syntactically.
However,
CMyOwnDlg *Parent = dynamic_cast <CMyOwnDlg *> (GetParent());
in the function of the control caused an error: RTDynamicCast threw an exception.
|
|
|
|
|
Did you set the compiler option to enable RTTI (Run time type info)? If not use DYNAMIC_CAST as this will work without the compiler option.
John
|
|
|
|
|
What is the implication of using virtaul constructors?how to acchieve the model of the same even thogh C++ does not have them?
|
|
|
|
|
tom groezer wrote: virtaul constructors
such a thing doesn't exist... so I don't know where you're taking your questions from, but they're erroneous
|
|
|
|
|
It depends on what you mean. It's true that C++ doesn't support virtual constructors per se, but there is a design pattern called the virtual constructor idiom[^] which may be what the OP is after. Many programmers and designers use the term "virtual constructor" to refer to this idiom and are not talking about literally making constructors virtual.
Steve
|
|
|
|
|
What is your requirement, If you want to hide the details of Object creation,
Refer Factory, builder, .. patterns(Design Patterns)
Contructors are required to identify the class whose object is created. Making it virtual is meaning less.
Best Regards
Raj
|
|
|
|
|
It depends on what you mean. It's true that C++ doesn't support virtual constructors per se, but there is a design pattern called the virtual constructor idiom[^] which may be what the you're after. Many programmers and designers use the term "virtual constructor" to refer to this idiom and are not talking about literally making constructors virtual.
Steve
|
|
|
|
|
|
A constant variable is one that can't be changed (at least the compiler won't let you do it
directly).
In-class means it is a member of a class.
For usage, the section "How do I define an in-class constant?" in Bjarne Stroustrup's
C++ Style and Technique FAQ[^] may help 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
why is v[i] = i++; and f(v[i],i++); deemed inappropiate in C++
|
|
|
|
|
A bit cryptic, maybe confusing, that's all (I dont' deem the above inappropiate).
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.
|
|
|
|
|
It's something which has been proposed by Stroustup. Basically it is involvind some kind of two reads in a single operation. Any furtehr light. How to identidy such situation. will a[j] = i++ be appropriate?
|
|
|
|
|
tom groezer wrote: will a[j] = i++ be appropriate?
yes, because the variable you use as an index, is not being modified on the same line of code. i++ means, return i, then increment it. a[j] will definately contain the old value of i. The thing is that when i is incremented is not clear. Does a[i] = i++ set the a at the index equal to the old i, or the new i ? It may be defined ( I don't think it is, I think it's compiler specific ), but it's at least hard to read.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: I don't think it is, I think it's compiler specific
AFAIK the postfix increment operator acts the following way:
use the current value of the variable in the statement and then increment it.
Christian Graus wrote: but it's at least hard to read.
I completely agree on the above.
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: Christian Graus wrote: I don't think it is, I think it's compiler specific
AFAIK the postfix increment operator acts the following way:
use the current value of the variable in the statement and then increment it.
This is absolutely correct and of course considered C/C++ basics. 
I think Christian meant that the statement
a[i] = i++; is an undefined behavior and the resulting operation is compiler specific.
It's undefined what index of a will be operated on.
If i equals 1 before the statement above, will a[1] be assigned 1 or will a[2] be assigned 1?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
IMHO should be always
a[1] = 1;
because a[i] = i++; is one statement.
What do you think about?
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
