Re: Writing to ctl on proerty page b4 OnInitDialog

See below...
On Wed, 3 Dec 2008 07:47:01 -0800, Jimbo_Jimbob_Jiminator
<JimboJimbobJiminator@discussions.microsoft.com> wrote:


****
This is a common error. It presumes that you know there is a property sheet which has a
member called pPage3 and that pPage3 has a member called CEditCtl.member_function.

Code like this sets my teeth on edge. The dialog should neither know nor care who
maintains this information, and most especially should not know there is a property page,
what it is, or what methods or controls it has.

What you do is define ONLY the interface to the property sheet. You call a method of the
property sheet that says "Set this information". The property sheet stores the
information. That's all the caller ever sees or knows or cares about.

Next, the property sheet has an abstract interface. It sends a message tothe currently
active page, which simplistically you can characterize as a <information-type, string>
pair. If the page does not recognize the information-type code, it does not handle the
message, and nothing goes wrong. The data is still sitting there in the property sheet.
If what you have called "page3" is the active page, it gets the message, understands the
information-type and stores the value IN WHATEVER WAY IT FEELS LIKE TODAY. Nobody ever
has to know HOW it saves it, what the control is, what methods of the control are
involved, etc. This kind of information should NEVER be known to the creator of the
information.

You can assume that ANY time you try to manipulate the controls of a CDialog/CPropertyPage
from outside the class that manages the page, you have made a deep and fundamental design
error. A good way to determine that this has happened is if you ever need to make a
control member 'public'. Control variables should NEVER be public, nor should you create
public methods that manipulate them unless you use the model

void CMyPage::SetSomething(BOOL b)
    {
     something = b;
     if(c_Something.GetSafeHwnd() == NULL)
         return;
     c_Something.SetCheck(something ? BST_CHECKED : BST_UNCHECKED);
    }

and you will handle the value transfers on OnInitDialog and OnSetActive. Similarly, you
cannot use getters that rely upon the existence of a control:

BOOL CMyPage::GetSomething()
   {
    if(c_Something.GetSafeHwnd() == NULL)
      return something;
    return c_Something.GetCheck() == BST_CHECKED ? TRUE : FALSE;
   }

but your client should NOT know about any of these methods; that is none of its business.
It is the responsibility of the property sheet to manage values (the pattern is that the
container of displays manages the displays)
****


****
The problem is that you are trying to do it completely wrong, as I outlined above. There
is no reason you EVER need to know anything other than the property sheet accepts a
certain value, period. How and where it is stored is none of your business outside of the
dialog.

Now, to solve the next problem, note that the message is always sent to the ACTIVE window.
So what happens if your window is not active, or has not even been created?

Well, the same technique you used before can be used in the other direction. From time to
time, a given page asks of its property sheet, "I want this data". It can do it by
sending a message to the property sheet, or by treating the property sheet as a "document"
and itself as a "view". It can call a known method of the property sheet to get the data.
It would do this in OnInitDialog, and in OnSetActive. Thus, while the dialog is not
visible, its contents are bogus, but the act of creation or becoming visible causes it to
update itself so it is now correct.

Note now that the message about information can be simplified, to "I have new data" and
the active page just reaches up into the "document" (the property sheet) and retrieves
whatever it thinks it needs; you don't even have to pass the data around to it.

If the dialog actually accepts user input, it can notify the property sheet that it has
made a change because, isntead of just setting a variable, it can call a 'setter'
function. The setter function knows that for its data, the owner needs to know the user
typed something, so it can SendMessage to its parent information that data has changed,
and even encode the information-type code in the message, which will then cause whoever
wants the data to reach into the property sheet (using a getter function) and retrieve the
data and use it for its own purposes. Note that at no time does the client of the
property sheet have to know or care about any of the details of the implementation of the
pages; the property sheet itself does not have to know or care about any of the details of
the implementation of the pages; and the pages only know how to get data from their
property sheet parent/"document"; the client of the property sheet only has to know that
once data is placed in the property sheet that it will magically appear in whatever pages
need it.

You get
    (a) something that is more robust
    (b) something that provides nice, abstract interfaces
    (c) something that is relliable
    (d) something that is easy to maintain

What's not to like?
                    joe
*****


Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm