You know, I think encapsulation may have been the wrong word. I agree using
member functions (setter, getter) is how you encapsulate in the first place.
And, these functions would need to public or it's useless. What I really
meant is insulation and modularity. That is exposing on the minimal interface
possible.
Messaging allows this interface to be smaller. But, I get your point, that
then I will do that. At that point, the SHEET acts as a sort of proxy to the
PAGE, only a step away from a pointer to a function pointer. As you stated,
member functions or access data. You had mentioned that and I thought I just
Calling a method in a class does not violate any encapsulation rule at all.
As a matter of fact that is how you achieve encapsulation.
If you were to access the Page object directly, then you were violating the
encapsulation rule.
But with what I posted, the sheet is hiding its pages, and only giving
access to them through method calls.
Now if you were going the other way around (trying to call a method of the
parent window from the page), then you will be violating a bunch of rules.
To get around that, as recommended, you can use windows messages, then you
don't really care who the parent is, as long as it handles the message.
Which means that you are not tightly coupled with that parent class (no
circular dependency).
In the situation of doing something with a child, I think that SendMessage
is over kill and somewhat restrictive (In some situations it makes sense, as
Joe pointed out, if you want to do the same thing with bunch of children, I
guess SendMessageToDesendents is a good way if you are only passing two
parameters, and you don't care about a return value).
But calling a method on the Sheet to tell its child to do something is the
preferred way of manipulating an object.
AliR.
"Jimbo_Jimbob_Jiminator" <JimboJimbobJiminator@discussions.microsoft.com>
wrote in message news:65496715-AE36-4A11-A401-51DCF4D7CA8A@microsoft.com...
It seems that the ProertySHEET is modeless because I use
PropSheet.Create().
OK, but if I call pPropSHEET->DoSomethingToAPage() from my main dialog,
aren't I then violating the rules of encapsulation and data hiding?
Shouldn't
then a Windows message be sent to the PropSHEET? Then the call would be
OnDoSomethingToAPage().
I do recall Joe mentioning working through the PropertySHEET using the
PropertyPAGE as a sort of view. I can see that. In this scenario, there is
not much modularity between the PAGE's and SHEET. I don't guess any
messaging
would have to be sent between the PAGE's and SHEET. True?
I just figured if there was something on the PAGE that didn't involve
anything else, I would message the PAGE to deal with it.
I guess it just gets down to how much should be modular. The primary
dialog
should never be manipulating data in the PAGE or calling member functions
of
the PAGE unless there's a very compelling reason. I get that now (from
previous post).
At what point should the SHEET be allowed to access the PAGE directly?
These
seem, from my conversations here, more inherently coupled.
How much of the SHEET should the dialog be able to access? Should as much
as
possible be messaging? That is now how my thought process has shifted.
Nearly
everything should be messaging if it can.
If I don't message the PAGE directly, then I will message the SHEET.
It's just nebulous as to where these lines should be drawn.
Jim
"AliR (VC++ MVP)" wrote:
I remember your origianl thread!
I have a question? Is this Property sheet modeless or modal?
If we are talking about the modeless propertysheet
You don't need to send a message from the parent to the PropertyPage.
You
can provide a method in your CPropertySheet derived class which will
endup
calling the CPropertyPage derived classes method. (I think this came up
in
your original post).
class CMyPropertySheet : public CPropertySheet
{
......
public:
BOOL DoSomethingToAPage(....);
private:
CMyDialog1 m_Page1;
CMyDialog2 m_Page2;
}
class CMyDialog2 : public CPropertyPage
{
public:
BOOL DoSomething(...);
}
BOOL CMyPropertySheet::DoSomethingToAPage(....)
{
if (m_Page2.IsWindow())
{
return m_Page2.DoSomething(....);
}
return FALSE;
}
Now from you main window after you have created your propertysheet class
you
can call DoSomethingToAPage.
Now if this is a model dialog, you can't do the above, or SendMessages
from
the main window.
AliR.
"Jimbo_Jimbob_Jiminator" <JimboJimbobJiminator@discussions.microsoft.com>
wrote in message
news:DF84642E-A7B7-4A66-83A8-72C3FD44EF98@microsoft.com...
In a previous post a while back, Joe pointed out that my structure was
incorrect on my app (in fact, I believe the quote was, paraphrased,
"that
kind of code sets my teeth on edge").
I was, and still am, sending messages to the parent dialog. I can send
a
message to the parent dialog from the Property Pages but have not had
any
luck with the reverse.
I am trying to move it in the right direction by sending messages to
the
Property Page from the parent.
To send a message to the parent I use:
AfxGetMainWnd()->PostMessage(WM_CLOSE, 0, 0);
LRESULT Rslt = ::SendMessage(m_pMainWnd->m_hWnd ,UWM_INIT_PG1, 0, 0);
I have also seen:
GetParent()->SendMessage(WM_COMMAND, MAKEWPARAM(Something(), 1000),
(LPARAM)m_hWnd);
Of course, I add the appropriate message map and afx_msg entries. I
followed
the same format to send a message to Property Page, but no luck.
Here is the program structure:
The program is a small program structured as follows:
Dialog bases app.
App creates primary dialog (done by VS2005)
Primary dialog creates Property Sheet
Property Sheet creates 4 property pages
Regards,
Jim