I was wondering how Visual Studio associates MFC CDialog
derived classes with their corresponding dialog resources. I'm not interested in how the connection is made at run time (as asked here), but rather at design time.
When I add a message handler to a dialog, how does it know which class to add the handler to.
Also, is it possible to have several CDialog
derived classes associated with the same dialog resource and vice versa?
I have searched the project directory for the IDD_SOMEDIALOG
string but have only found it in SomeDialog.h
, resource.h
and Project.rc
in the expected places so I guess it somehow deduces the connection from those files, most likely the enum in SomeDialog.h
:
// in class CSomeDialog:
enum { IDD = IDD_SOMEDIALOG };
I'm asking this mostly out of curiosity.
To add to Ruddy's answer:
I noticed that some of my dialog classes in which I replaced the
enum { IDD }
withstatic const int IDD
was not any longer associated with its dialog resource. Reverting to the enum re-associated them. So it seems that visual studio parses the source code to determine the relationships.As for resource sharing, it would be ambiguous as to which class should receive the event handler code. Class sharing seems to be be impossible since it relies on the
IDD
which can not be assigned to aIDD_SOMETHING
andIDD_SOMETHING_ELSE
simultaneously.It depends on what version of dev studio.
In VS6 it was all kept in the CLW (Class Wizard File).
In newer versions of dev studio it doesn't use the CLW anymore and I don't know specifically how it knows, but i suspect its a live parsing instead of using a cached CLW.
As for having multiple derived dialogs using the same resource, it can be done manually. You can duplicate the created class files and rename them and remove the enum from header and edit the use of the IDD enum in the source file to be the actual dialog resource id (IDD_SOMEDIALOG).
AFAIK Dev Studio will only 'happily' handle one class to a dialog at a time. In my experience trying to re-use a dialog resource like this just ends up in a bit of battle with MFC & Dev Studio since they were not intended to do this.