Object Tree Model is a very important project setting, which influences object recognition in the Object Browser. Selection of just one of the models would not make it possible to simply switch between models in the future, keeping the existing scripts; since these models are altogether different. In this recipe we will consider two supported Flat and Tree models, their pros and cons, and provide counsel on the choice of a certain model for your project.
Launch a standard application Paint from the Windows suite by navigating to Start | All Programs | Accessories | Paint.
To see the difference between two models, we need to perform the following steps:
- Open the properties of the project (right-click on the name of the project and navigate to Edit | Properties).
- Opt for the General group of options.
- Set the Object tree model parameter value to Tree, as shown in the following screenshot:
- Begin recording of the script and click on any button on the Home panel in the Paint window, and then stop the recording.
- If, in the meantime, the NameMapping window appears, click on the Cancel button.
- In the result, the following script string will be recorded:
Sys.Process("mspaint").Window("MSPaintApp", "*").Window("UIRibbonCommandBarDock", "UIRibbonDockTop").Window("UIRibbonCommandBar", "Ribbon").Window("UIRibbonWorkPane", "Ribbon").Window("NUIPane").Window("NetUIHWND").Click(260, 78); - Reiterate steps 1 through 4, however, on the first step, set the Object tree model parameter value to Flat.
- In the result, the following code will be recorded:
Sys.Process("mspaint").Window("MSPaintApp", "*").Window("NetUIHWND").Click(260, 78);
The difference between the Flat and the Tree models is clearly distinguishable; the Tree model yields a much greater number of nested objects as compared to the Flat one. This occurs due to the Tree Object Browser mode displaying controls elements in exactly the same way as they are located in the tested application itself. In the Flat model, all the controls elements are sibling elements to the window, regardless of their internal mapping in the application. As the toolbar, usable in Paint (Ribbon), is quite a complicated control element, we observe a complex element structure in the Tree model between the window and the toolbar; there are to be found as many as four elements. Naturally, the Flat model seems more user friendly, and it is indeed so. If you are not running up against a difficulty in naming the controls elements in this mode, this is to be preferred as your first option.
Sometimes, however, there arise use cases that make it difficult to apply the Flat model. For example, if there are too many eponymous controls elements in the window that are instanced to the same classes, then all of them are outputted equally on the same level of the hierarchy (that is, as sibling elements in relation to the window they have taken after); therefore, it becomes quite hard to sort out where each and every controls element exactly belongs. The only way of extrication consists in using the indices (which is not really a convenient thing). This is why the thumb rule for choosing Object Tree Model runs as follows: for simple applications where you don't have problems with recognizing controls, use Flat model. In other cases use Tree model.
If you use the Tree model, it is recommended that you should apply the controls element of the NameMapping project item and its extension of Aliases. NameMapping allows us to assign the controls elements with simple and brief names, while the Aliases allows us to create a hierarchy from these named objects (regardless of the way they have been mapped in the application and in the Object Browser).
- If you are applying the Flat model and often come up against an issue of elements recognition with the same names, it is recommended that you revert to the Finding objects by properties' values recipe
- If you test web applications, we recommend reading the Choosing Web Tree Model recipe in Chapter 10, Testing Web Applications