Fundamental question about visibility

Casper Bang

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

Jul 19 '05 #1

Subscribe Post Reply

4203

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. 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.
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

Jul 19 '05 #2

Casper Bang

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.
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.
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

Jul 19 '05 #3

Casper Bang wrote:

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. :-)

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?
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()

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

Jul 19 '05 #4

red floyd

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();
}

Jul 19 '05 #5

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

Jul 19 '05 #6

red floyd wrote:

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

Jul 19 '05 #7

Fundamental question about visibility

Similar topics