How does visual studio associate mfc dialog classes with dialog resources?

Question

I was wondering how Visual Studio associates MFC CDialog derived classes with the corresponding dialog resources. I'm not interested in how the connection is made at runtime (as given here ), but rather at design time.

When I add a message handler to the dialog, how does it know which class to add the handler to. Also, is it possible to have multiple CDialog derived classes associated with the same dialog resource, and vice versa?

I searched the project directory for the IDD_SOMEDIALOG line, but only found it in SomeDialog.h , resource.h and Project.rc in the expected places, so I assume that it somehow outputs the connection from these files, most likely an listing in SomeDialog.h :

 // in class CSomeDialog: enum { IDD = IDD_SOMEDIALOG }; 

I ask for this mainly out of curiosity.

Answer 1

It depends on which version of dev studio.

In VS6, everything was saved in CLW (class wizard file).

In newer versions of dev studio, it no longer uses CLW, and I don’t know exactly how it knows, but I suspect it is parsing instead of using cached CLW.

As for having multiple derived dialogs using the same resource, this can be done manually. You can duplicate the created class files and rename them, as well as remove the enumeration from the header and edit the use of the IDD enumeration in the source file as the actual dialog resource identifier (IDD_SOMEDIALOG).

AFAIK Dev Studio will only happily process one class in a dialog at a time. In my experience, an attempt to reuse a dialog resource like this just ends in a battle with MFC and Dev Studio, as they are not designed for that.

Answer 2

To add an answer to Ruddy:

I noticed that some of my dialog classes, in which I replaced enum { IDD } with static const int IDD , are no longer associated with its dialog resource. A return to the listing is re-associated with them. It looks like the visual studio is analyzing the source code to determine the relationship.

Regarding resource sharing, it would be ambiguous which class should receive the event handler code. Sharing classes seems impossible because it relies on IDD that cannot be assigned at the same time as IDD_SOMETHING and IDD_SOMETHING_ELSE .