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;
begin
inherited ConnectTo('TMyForm', nil);
Init;
Bind;
end;
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.