Problem with using CDialog from CPropertyPage

[anshugoel51]

Hi,

I have CPropertySheet which contain multiple CPropertyPage as tabs. In one of the CPropertyPage i have a button and clicking on the button launches a CDialog. i am trying to get the control to CPropertyPage calling GetParent() method inside the CDialog class methods but somehow i don't get the right parent window and when i try to access the members of CPropertypage it throws Access Violation Exception.

Following is the code i have used:


CDialog *parentDialog = (CDialog *)GetParent(); // which return the CDialog as WS_POPUP style is used
CPropertyPage *parentPage = (CPropertyPage *)parentDialog->GetParent(); // trying to get the CPropertyPage from where the dialog is launched.
DResourceStateMgr dSrcStateMgr(parentPage->m_psp.hInstance); // throws Access Violation exception.

Same thing used to work in the Visual studio 2008 but when i moved to visual studio 2013 it throws exception.

[GCDEF]

The default parent of a CDialog is the application's main window. Pass your CPropertyPage to your CDialog's constructor.

[anshugoel51]

I have tried that also still it does not return right parent when i call getParent()

[GCDEF]

Show the code where you create the dialog.

[Arjay]

Another way to approach the problem is to apply a document\view architecture type approach to property pages.

The goal of the doc/view architecture is a separation of concerns between the views and the data (or business logic). In MFC, we called it doc/view, now-a-days it is referred to as MVC, MVVM and other patterns.

Still the nuts and bolts are the same - which is separate the view from the data and the logic.

How this applies here to the property page problem is that (IMO) it is a losing battle to try to access data through the UI controls of some other UI entity (prop page, dialog, view whatever).

Of course, if you are in a child dialog and you need to access data from a parent dialog, it seems perfectly reasonable use GetParent() and access the parent's data through the parent's controls.

This works until you get the wrong parent, or the child dialog is displayed from more than one parent dialog - now you have to go through the song and dance of getting the parent and deciding which parent it is. Is it ParentDialog1 or ParentDialog2? What happens if you open the child dialog from another parent dialog or a view?

This approach doesn't scale and really only works for the most simplest in dialog or view layouts.

So what happens if we apply a doc/view architecture approach to the problem? With a doc view approach (d/v) the data is separated from the views. Each view (a dialog in this case) only operates on data and doesn't know about other views. So there isn't a need to know that a dialog is a child of another dialog, which is a child of a view, etc.

What we do is create a 'document' that contains the data for the application, we hold onto the document and pass it to the various UI 'views'. So for a property sheet with a bunch of prop pages, a document is passed to the sheet and each page binds to the data in the document that pertains to the page. If one of the pages opens a child dialog, the document is passed to the child dialog (and the UI controls are bound to the appropriate data in the document). If the child dialog is closed with "OK', it updates the data in the document; if 'cancel' is pressed it doesn't update the data. If fact, each ui element (i.e. view) takes that approach and is responsible for updating the document,... or not.

If page 3 opens a child dialog and it needs to access some data from what is shown on page 1, is simply references the page 1 data in the document. This is much simpler than the child dialog figuring out it was opened in page 3 and the figuring out how to access the data in page 1 (or was the data in page 2?).

Granted, this approach is different from the traditional approach of accessing data through UI components. If you can get your head around this, I think you will find that the code ends up being simpler and way easier to debug. You also have the flexibility of changing the UI around without have to worry about keeping track of the parent hierarchy.

See the following link for a reply of mine from years ago in Code Guru. The link has a zipped up sample that takes this approach with a property page in wizard mode (just ignore the wizard as the d/v concept is the same).

http://forums.codeguru.com/showthrea...80#post1732980