Mr. Cluey : How To ...? : Windows with many parents

Does anyone know of a way to have a single dialog box declared with more than one parent?

Michael Richters (Dimensional Insight, Inc) raised this question. The answer is that yes, it can be done. The implementation in general is fairly straight forward, although there are some design issues that should be addressed first.

Design Concerns

The primary concern here is Should you ever want to do that?

Are they really the same dialog?

Well, we already know the answer to that. They are not the same - the merely have a close resemblance to each other. We can list two differences off the top without even seeing the application in action

• The have different parents
• They are not invoked the same way.

It is likely that there are other differences as well. For instance, the two distinct instances of the FileOpen dialog may be opening different types of files (one opens text files, another opens images) - the default type could be different, or the list of file filters. If there is a help button, do both dialogs take you to the same page in the documentation (and if they do, are you certain that they should? After all, if you are doing two different things, the explanation will probably differ).

Should the test script really care if they are the same?

That depends on what you are testing. If you are testing that specific dialog, or that specific function, maybe. If you are testing the application, almost certainly not.

Dialogs, especially common ones like the FileOpen dialog, are usually interfaces to some function in the application. The user is being queried for similar data, but it is going to be used in a different way... this alone suggests that the windows should be different (mind you, they should share a lot, by which I mean, of course, a whole lot, of code).

So you would definitely definitely care when testing that interface, and the actual dialog itself (which is why you might really want to have them be distinct, by the argument above.

But when you are testing the application, the dialog becomes an implementation detail that should be hidden from the test script.

In other words, instead of code that looks like

A.mnuOpenFile.Pick() ; //pick the menu item to invoke the dialog
dlgFileOpen.SetFileName("C:\partner.ini") ;
dlgFileOpen.OK.Click () ;

//.....
B.mnuOpenFile.Pick() ; //pick the menu item to invoke the dialog
dlgFileOpen.SetFileName("C:\autoexec.bat") ;
dlgFileOpen.OK.Click () ;
//

you want to have scripts that look like this:

A.OpenFile("C:\sparkles.txt") ;
//...
B.OpenFile("C:\sparkles.gif") ;

or even better

theApp.OpenText("C:\sparkles.txt") ;
//...
theApp.OpenImage("C:\sparkles.gif") ;

Part of Richter's concern was that keeping track of all of the different names a dialog can have is a pain. And I agree. But the way to solve that problem is to write functions and methods that wrap access to the dialogs, rather than trying to cram them all in under the same name.

Multiple Parent Implementation

Sigh... you've decided that you want to do it anyway.

The implementation is fairly straight forward. Somewhere you are going to have to keep track of all of the possible parents this window can have. The best place to do that is inside the window itself. So the window will have a method that returns a list of possible parents.

To keep things simple, the first window in that list will be the default parent. An alternative would be to use a phony window as the default parent.

The key method in this class will be the GetParent() method. It will scan through the list of parents, trying to find one that has this window as a child. If it finds a match, it returns the corresponding parent. When no match is found, the default parent is returned.