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().Wan tToBeCalled() 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

[WW]

Re: Fundamental question about visibility

Casper Bang wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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().Wan tToBeCalled() would be the right way I guess...)[/color]
[SNIP][color=blue]
> What fundamental "visibility issue" haven't I understood correct?[/color]
[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

[Casper Bang]

Re: Fundamental question about visibility

[color=blue]
>There are no methods in C++. There are member functions[/color]
Yeah I remember hearing that before, however I assume when such a prototype
is illustrated within a C++ class{}construc t, calling it method, function or
procedure is semantically the same and hardly relevant to my original
question.
[color=blue]
> No. I must say that it seems that you have not understood object oriented
> design.[/color]
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.
[color=blue]
> 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[/color]
idea[color=blue]
> about what they are.[/color]

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::On ParseMe()

Hope this helps,
Casper

[WW]

Re: Fundamental question about visibility

Casper Bang wrote:[color=blue][color=green]
>> There are no methods in C++. There are member functions[/color]
> Yeah I remember hearing that before, however I assume when such a
> prototype is illustrated within a C++ class{}construc t, calling it
> method, function or procedure is semantically the same and hardly
> relevant to my original question.[/color]

It is not relevant to the queston, but he way you have asked it. :-)
[color=blue][color=green]
>> No. I must say that it seems that you have not understood object
>> oriented design.[/color]
> 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.[/color]

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?
[color=blue]
> 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:[/color]

;-)
[color=blue]
> // 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::On ParseMe()[/color]

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(C MainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};


// Somewhere in a CModifiedEdit.c pp, 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::CM ainWindow():m_w ndEdit(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

[red floyd]

Re: Fundamental question about visibility

Casper Bang wrote:[color=blue]
> [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::On ParseMe()[/color]

void CMainWindow::On KeyDown(/* params */)
{
OnParseMe();
}

[WW]

Re: Fundamental question about visibility

WW wrote:
[SNIP]
Update
[color=blue]
> // Overide the CEdit class so we can capture CTRL + ENTER events
> class CModifiedEdit : public CEdit
> {
> CMainWindow *parent;[/color]

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.)
[color=blue]
> public:
> CModifiedEdit(C MainWindow *mamma) : parent(mamma) { ; }
> afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
> };[/color]
[SNIP]
--
WW aka Attila

[WW]

Re: Fundamental question about visibility

red floyd wrote:[color=blue]
> Casper Bang wrote:[color=green]
>> [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::On ParseMe()[/color]
>
> void CMainWindow::On KeyDown(/* params */)
> {
> OnParseMe();
> }[/color]

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

[jeffc]

Re: Fundamental question about visibility


"WW" <wolof@freemail .hu> wrote in message
news:bkqkn3$5ld $1@phys-news1.kolumbus. fi...[color=blue]
> Casper Bang wrote:[color=green]
> > 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.[/color]
>
> There are no methods in C++. There are member functions.[/color]

Oh brother. <warning>Pedant Police<warning>

[jeffc]

Re: Fundamental question about visibility


"Casper Bang" <casper@jbr.d k> wrote in message
news:3f70dea1$0 $24709$edfadb0f @dread14.news.t ele.dk...[color=blue]
>[color=green]
> >There are no methods in C++. There are member functions[/color]
> Yeah I remember hearing that before, however I assume when such a[/color]
prototype[color=blue]
> is illustrated within a C++ class{}construc t, calling it method, function[/color]
or[color=blue]
> procedure is semantically the same and hardly relevant to my original
> question.[/color]

C'mon Casper, don't expect reason and common sense to hold back the wall of
flames....
[color=blue]
> Had I been more specfic in my example, people would criticize that this is[/color]
a[color=blue]
> ANSI C++ group not dealing with MSVC++ or the MFC library...[/color]

Of course - then you would have gotten no answer at all.

[WW]

Re: Fundamental question about visibility

jeffc wrote:[color=blue]
> "WW" <wolof@freemail .hu> wrote in message
> news:bkqkn3$5ld $1@phys-news1.kolumbus. fi...[color=green]
>> Casper Bang wrote:[color=darkred]
>>> 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.[/color]
>>
>> There are no methods in C++. There are member functions.[/color]
>
> Oh brother. <warning>Pedant Police<warning>[/color]

Please, if you *know* what method means in the realm of the C++ language...
by all means, post it here!

--
WW aka Attila

[WW]

Re: Fundamental question about visibility

jeffc wrote:[color=blue][color=green]
>> 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...[/color]
>
> Of course - then you would have gotten no answer at all.[/color]

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

[jeffc]

Re: Fundamental question about visibility


"WW" <wolof@freemail .hu> wrote in message
news:bksbbf$se3 $2@phys-news1.kolumbus. fi...[color=blue]
> jeffc wrote:[color=green][color=darkred]
> >> 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...[/color]
> >
> > Of course - then you would have gotten no answer at all.[/color]
>
> 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.[/color]

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?

[jeffc]

Re: Fundamental question about visibility


"WW" <wolof@freemail .hu> wrote in message
news:bksbbe$se3 $1@phys-news1.kolumbus. fi...[color=blue][color=green][color=darkred]
> >>
> >> There are no methods in C++. There are member functions.[/color]
> >
> > Oh brother. <warning>Pedant Police<warning>[/color]
>
> Please, if you *know* what method means in the realm of the C++[/color]
language...[color=blue]
> by all means, post it here![/color]

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.

[WW]

Re: Fundamental question about visibility

jeffc wrote:[color=blue]
> "WW" <wolof@freemail .hu> wrote in message
> news:bksbbf$se3 $2@phys-news1.kolumbus. fi...[color=green]
>> jeffc wrote:[color=darkred]
>>>> 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.[/color]
>>
>> 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.[/color]
>
> 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?[/color]

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

[WW]

Re: Fundamental question about visibility

jeffc wrote:[color=blue]
> "WW" <wolof@freemail .hu> wrote in message
> news:bksbbe$se3 $1@phys-news1.kolumbus. fi...[color=green][color=darkred]
>>>>
>>>> There are no methods in C++. There are member functions.
>>>
>>> Oh brother. <warning>Pedant Police<warning>[/color]
>>
>> Please, if you *know* what method means in the realm of the C++
>> language... by all means, post it here![/color]
>
> 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.[/color]

You mean the quote that some people, sometimes may call virtual member
functions methods? A very widely accepted definition. See the original
post of this thread.

If you choose to use a vague and confusing term (with no exact definition)
by all means do it. But then do not wonder if people think you are not here
to help. BTW as it happens it is not only me who thinks that it is not the
luckiest thing to use the non-existing C++ term method in C++ discussion.
Steve Dewhurts's (not so) new book just says the same. Conincidence that a
co-worker of Bjarne Stroutrup, the lead designer and implementer of the
first non-cfront C++ compiler, former principal on the ANSI/ISO C++
standardization committee happens to have the same opinion? Maybe. Maybe
he just happened to eat somewhere the same poisoned food I did. But I beg
to think otherwise.

--
WW aka Attila