 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Casper Bang
Guest
|
 Posted: Tue Sep 23, 2003 10:56 pm Post subject: Fundamental question about visibility |
 |
|
My question is fundamental I beleive but it has been teasing me for a while:
I have two classes in my app. The first class is instantiated as a member of
my second class. Within this first class, a method (event) needs to be able
to invoke methods of the second class. With static classes its possible but
this is not desirable. There's obviouly some visibility problem I am not
familiar with. It is not a parent-child relationship since there's no
enheritance is it? (If so, something like GetParent().WantToBeCalled() would
be the right way I guess...)
class FirstClass{
public:
void TriggeringEvent(); // When this is called, invoke
WantToBeCalled of CS
};
class SecondClass{
public:
FirstClass FS;
void WantToBeCalled(); //
};
SecondClass CS;
....
What fundamental "visibility issue" haven't I understood correct? I've
looked at "export" directives and also suspect namespaces could have
something to do with it but I am getting tired or trial-and-error without
success.
Thanks in Advance,
Casper
|
|
| Back to top |
|
 |
WW
Guest
|
| Posted: Tue Sep 23, 2003 11:24 pm Post subject: Re: Fundamental question about visibility |
|
|
Casper Bang wrote:
| Quote: | My question is fundamental I beleive but it has been teasing me for a
while:
I have two classes in my app. The first class is instantiated as a
member of my second class. Within this first class, a method (event)
needs to be able to invoke methods of the second class.
|
There are no methods in C++. There are member functions. Some people call
cirtual member functions methods, but since this meaning is not all well
known, it is not recommended to refer to C++ member functions as methods in
a C++ language discussion. Simply it can happen that people will
misunderstand. For example your example code did not contain any method for
those, who only call virtual member functions methods.
| Quote: | With static
classes its possible but this is not desirable. There's obviouly some
visibility problem I am not familiar with. It is not a parent-child
relationship since there's no enheritance is it? (If so, something
like GetParent().WantToBeCalled() would be the right way I guess...)
[SNIP]
What fundamental "visibility issue" haven't I understood correct?
[SNIP] |
No. I must say that it seems that you have not understood object oriented
design. What you wanted to do above can be done with some "tricks", but I
am not exactly sure that it has to be. Could you please describe what you
really want to do? In your code I see no concepts - not that you have no
concept, but the names of the example classes are too vague to have any idea
about what they are.
--
WW aka Attila
|
|
| Back to top |
|
|
Casper Bang
Guest
|
| Posted: Wed Sep 24, 2003 12:04 am Post subject: Re: Fundamental question about visibility |
|
|
| Quote: | There are no methods in C++. There are member functions
Yeah I remember hearing that before, however I assume when such a prototype |
is illustrated within a C++ class{}construct, calling it method, function or
procedure is semantically the same and hardly relevant to my original
question.
| Quote: | No. I must say that it seems that you have not understood object oriented
design.
That may be partly true practically, due to a mix of programming real OO |
Java and fake OO Visual Basic for 3-4 years. The hybrid paradigm C++ is thus
a completely new matter.
| Quote: | What you wanted to do above can be done with some "tricks", but I
am not exactly sure that it has to be. Could you please describe what you
really want to do? In your code I see no concepts - not that you have no
concept, but the names of the example classes are too vague to have any
idea
about what they are.
|
Had I been more specfic in my example, people would criticize that this is a
ANSI C++ group not dealing with MSVC++ or the MFC library but here goes
nothing:
// Overide CWndApp, defining our main application object
// This is our "Point of entry", in that the overidden InitInstance
// method is responsible for creating window(s) etc.
class CMyApp : public CWinApp
{
public:
virtual BOOL InitInstance();
};
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
public:
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or later.
When this happens, I am interested in calling the member funtion
CMainWindow::OnParseMe()
Hope this helps,
Casper
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 12:37 am Post subject: Re: Fundamental question about visibility |
|
|
Casper Bang wrote:
| Quote: | There are no methods in C++. There are member functions
Yeah I remember hearing that before, however I assume when such a
prototype is illustrated within a C++ class{}construct, calling it
method, function or procedure is semantically the same and hardly
relevant to my original question.
|
It is not relevant to the queston, but he way you have asked it. :-)
| Quote: | No. I must say that it seems that you have not understood object
oriented design.
That may be partly true practically, due to a mix of programming real
OO Java and fake OO Visual Basic for 3-4 years. The hybrid paradigm
C++ is thus a completely new matter.
|
May I suggest you getting hold of (once you have mastered C++ fundmentals)
the book with the title Multi-Paradigm DESING for C++ from Coplien?
| Quote: | Had I been more specfic in my example, people would criticize that
this is a ANSI C++ group not dealing with MSVC++ or the MFC library
but here goes nothing:
|
;-)
| Quote: | // Overide CWndApp, defining our main application object
// This is our "Point of entry", in that the overidden InitInstance
// method is responsible for creating window(s) etc.
class CMyApp : public CWinApp
{
public:
virtual BOOL InitInstance();
};
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
public:
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or
later. When this happens, I am interested in calling the member
funtion CMainWindow::OnParseMe()
|
Hmmm. That seems to be a flow in the MFC design. The edit control does
knwow it very well what Window owns it (parent) but it seems it has no way
to get the C++ object belonging to that Window. Is that true? Are you sure
you are unable to ask MFC to give you the parent C++ object? If this is so
the only easy C++ thing I can imagine is to add a non-default constructor to
CModifiedEdit taking a pointer to its parent C++ object and initialize it on
the initializer list of the CMainWindow constructor:
class CMainWindow;
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;
public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
// Somewhere in a CModifiedEdit.cpp, far far away
// or int the CModifiedEdit.h after the class declaration and
// including CMainWindow.h to enable inlining
// (don't forget header guards!):
afx_msg void CModifiedEdit::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
// Do whatever
parent->OnParseMe();
}
// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};
CMainWindow::CMainWindow():m_wndEdit(this) {
// The rest
}
===
<OT>
And of course there is a Windows Way[TM]. Bind the execution of OnParseMe()
to a user defined Windows Message. In that way anyone knowing the main
window handle will be able to ask it to reparse using a SendMessage
(synchronous) or Postmessage (asynchronous).
</OT>
--
WW aka Attila
|
|
| Back to top |
|
|
red floyd
Guest
|
| Posted: Wed Sep 24, 2003 12:39 am Post subject: Re: Fundamental question about visibility |
|
|
Casper Bang wrote:
| Quote: | [redacted]
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or later.
When this happens, I am interested in calling the member funtion
CMainWindow::OnParseMe()
|
void CMainWindow::OnKeyDown(/* params */)
{
OnParseMe();
}
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 12:40 am Post subject: Re: Fundamental question about visibility |
|
|
WW wrote:
[SNIP]
Update
| Quote: | // Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;
|
Here I hope a *lot* that CEdit does have a virtual destructor. In our case
it does not really matter (there is no descruction for a pointer and Windows
will release the memory properly) but according to Standard C++ it is better
be there. (Also in your code CMainWindow will always destroy CModifiedEdit
as CModifiedEdit, but later if you go dynamic about the GUI it might not be
the case.)
| Quote: | public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
[SNIP] |
--
WW aka Attila
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 12:50 am Post subject: Re: Fundamental question about visibility |
|
|
red floyd wrote:
| Quote: | Casper Bang wrote:
[redacted]
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner
or later. When this happens, I am interested in calling the member
funtion CMainWindow::OnParseMe()
void CMainWindow::OnKeyDown(/* params */)
{
OnParseMe();
}
|
Please indent your source code when posted here.
And no, not really. Doing this will distort OOD, where it is said: every
class is responsible for itself. In your case you would put all the
knowledge of the required operations into the Window, which then would need
to "work externally" on the edit control object. Unless of course you are
intended to use the Chain of Responsibility pattern, and you have meant that
the edit control class will do whatever it needs to and then signal to MFC
that it has to still pass the message up to the onwer as well. While this
approach may be sufficient in many case it has the drawback of possibly
using heavier machinery for the task delegation and also that whatever the
main window does *must* be done *after* what the edit control does.
<OT>
Unless of course MFC supports delegating to the owner (and returning) at any
point in the message handler - but that is off-topic here. BTW I don't know
if I did (I guess I did) mention this in my reply to the OP, but IMHO since
it is MFC the best would be to find an "MFC way" and check MSDN or whatever
to see if the edit control can "know" about its parent.
</OT>
As far as I understood the OPs intention was that it is the edit control who
knows when to parsem so that the main window does not need to know a change
in which control should trigger a parse and which is not. So IMO this means
that it is not enough to delegate message handling. Since in this case the
main window would always need to look at the message and ask itself: why the
heck did I get this, what should I do? It seems to be a cleaner desing if
the edit control (via Windows messages or C++ member function calls) would
ask definitely what it wants. And that is not "I had a key pressed", but "I
want you to parse".
--
WW aka Attila
|
|
| Back to top |
|
|
jeffc
Guest
|
| Posted: Wed Sep 24, 2003 2:52 pm Post subject: Re: Fundamental question about visibility |
|
|
"WW" <wolof (AT) freemail (DOT) hu> wrote
| Quote: | Casper Bang wrote:
My question is fundamental I beleive but it has been teasing me for a
while:
I have two classes in my app. The first class is instantiated as a
member of my second class. Within this first class, a method (event)
needs to be able to invoke methods of the second class.
There are no methods in C++. There are member functions.
|
Oh brother. <warning>PedantPolice<warning>
|
|
| Back to top |
|
|
jeffc
Guest
|
| Posted: Wed Sep 24, 2003 2:53 pm Post subject: Re: Fundamental question about visibility |
|
|
"Casper Bang" <casper (AT) jbr (DOT) dk> wrote
| Quote: |
There are no methods in C++. There are member functions
Yeah I remember hearing that before, however I assume when such a
prototype
is illustrated within a C++ class{}construct, calling it method, function
or
procedure is semantically the same and hardly relevant to my original
question.
|
C'mon Casper, don't expect reason and common sense to hold back the wall of
flames....
| Quote: | Had I been more specfic in my example, people would criticize that this is
a
ANSI C++ group not dealing with MSVC++ or the MFC library...
|
Of course - then you would have gotten no answer at all.
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 2:55 pm Post subject: Re: Fundamental question about visibility |
|
|
jeffc wrote:
| Quote: | "WW" <wolof (AT) freemail (DOT) hu> wrote in message
news:bkqkn3$5ld$1 (AT) phys-news1 (DOT) kolumbus.fi...
Casper Bang wrote:
My question is fundamental I beleive but it has been teasing me for
a while:
I have two classes in my app. The first class is instantiated as a
member of my second class. Within this first class, a method (event)
needs to be able to invoke methods of the second class.
There are no methods in C++. There are member functions.
Oh brother. <warning>PedantPolice
|
Please, if you *know* what method means in the realm of the C++ language...
by all means, post it here!
--
WW aka Attila
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 2:56 pm Post subject: Re: Fundamental question about visibility |
|
|
jeffc wrote:
| Quote: | Had I been more specfic in my example, people would criticize that
this is a ANSI C++ group not dealing with MSVC++ or the MFC
library...
Of course - then you would have gotten no answer at all.
|
I start to recall why did I killfile you once already. If you did care to
look at the thread you would see that it is old news. Not only he has got
an answer but it seems he was happy with it.
--
WW aka Attila
|
|
| Back to top |
|
|
jeffc
Guest
|
| Posted: Wed Sep 24, 2003 3:38 pm Post subject: Re: Fundamental question about visibility |
|
|
"WW" <wolof (AT) freemail (DOT) hu> wrote
| Quote: | jeffc wrote:
Had I been more specfic in my example, people would criticize that
this is a ANSI C++ group not dealing with MSVC++ or the MFC
library...
Of course - then you would have gotten no answer at all.
I start to recall why did I killfile you once already. If you did care to
look at the thread you would see that it is old news. Not only he has got
an answer but it seems he was happy with it.
|
Oh, you mean like when the guy asked "My question is where is the correct
(and best way) to initialize [static class member] variables?" and you
replied "Your question is Windows (DLL) specific." simply because he
mentioned he was writing a Windows DLL?
|
|
| Back to top |
|
|
jeffc
Guest
|
| Posted: Wed Sep 24, 2003 3:42 pm Post subject: Re: Fundamental question about visibility |
|
|
"WW" <wolof (AT) freemail (DOT) hu> wrote
| Quote: |
There are no methods in C++. There are member functions.
Oh brother. <warning>PedantPolice
Please, if you *know* what method means in the realm of the C++
language...
by all means, post it here!
|
I'll let you read about it "The C++ Programming Language" by Bjarne
Stroustrup. In the meantime, if you can possibly be any more pedantic,
please do. It would amaze me.
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Wed Sep 24, 2003 4:02 pm Post subject: Re: Fundamental question about visibility |
|
|
jeffc wrote:
| Quote: | "WW" <wolof (AT) freemail (DOT) hu> wrote in message
news:bksbbf$se3$2 (AT) phys-news1 (DOT) kolumbus.fi...
jeffc wrote:
Had I been more specfic in my example, people would criticize that
this is a ANSI C++ group not dealing with MSVC++ or the MFC
library...
Of course - then you would have gotten no answer at all.
I start to recall why did I killfile you once already. If you did
care to look at the thread you would see that it is old news. Not
only he has got an answer but it seems he was happy with it.
Oh, you mean like when the guy asked "My question is where is the
correct (and best way) to initialize [static class member]
variables?" and you replied "Your question is Windows (DLL)
specific." simply because he mentioned he was writing a Windows DLL?
|
Quit trolling. Look at the original post there. He uses the standard way
to initialize the members but it does not happen. At least that what he
says.
--
WW aka Attila
|
|
| Back to top |
|
|
Casper Bang
Guest
|
| Posted: Wed Sep 24, 2003 4:10 pm Post subject: Re: Fundamental question about visibility |
|
|
Adding custom constructors for passing of desired objects works but is not
exactly an elegant solution.
I solved it with the suspected GetParent call:
((<DerivedClass>)GetParent()).<MemberName>
^
Returns base class!
....but I had to cast to the overidden class and NOT rely on C++ to know
this! I would've thought GetParent pointed to the new class and not the old
but maybe this is simply a MFC specific twist. One more lesson learned!
Thanks for the feedback,
Casper
----------
"WW" <wolof (AT) freemail (DOT) hu> wrote
| Quote: | WW wrote:
[SNIP]
Update
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;
Here I hope a *lot* that CEdit does have a virtual destructor. In our
case
it does not really matter (there is no descruction for a pointer and
Windows
will release the memory properly) but according to Standard C++ it is
better
be there. (Also in your code CMainWindow will always destroy
CModifiedEdit
as CModifiedEdit, but later if you go dynamic about the GUI it might not
be
the case.)
public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
[SNIP]
--
WW aka Attila
|
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
