Automating popup windows and dialogs

I’ve been discussing Zombie, our internal testing framework and last time I talked about generating and using models which are classes used to drive a UI. Previously, I gave an example of a simple model that had a constructor called Connect. One reader, Eric Fortier commented asking how is the Connect constructor used? That’s a really good question.

The Connect constructor is a model specific override that looks like this:

constructor TMyFormModel.Connect;
  inherited ConnectTo('TMyForm', nil);

Of course, the next question is what does ConnectTo do? Well, as you can see it takes the classname of the form that’s modeled, the second parameter is for the caption but typically it’s not required so for  generated models it’s always nil. The ConnectTo constructor uses a special “wait” function which is similar to the Windows FindWindow API call but has the ability to continue searching for a window for a period of time before giving up or timing out. In fact, our framework has a whole set of Wait routines that use our own FindWindow replacement built on top of EnumWindows and EnumChildWindows that supports things like partial matches on window captions and limiting the search to only windows which  are visible to name only two.

Once the window in question has been located the model initializes all of the GEMs, or individual component models necessary to drive the windows various UI elements then calls Bind. The Bind method hooks up the mechanism used for the model to inspect the Window at a deeper level for example the RTTI of the object that instantiated the window. Binding to a window is a complicated process and it’s where the real power of the Zombie framework together with the VCL framework is  derived.

2 thoughts on “Automating popup windows and dialogs

  1. This may be a bad question, but is the Zombie framework source available out there someplace?

Comments are closed.