Nested domains support

Functional Tester recognizes two different kinds of nesting of objects, a parent-child nesting and an owner-owned nesting. A parent-child nesting occurs when one object is contained within another, such as a button on a form. An owner-owned nesting occurs when the owned object has its own top-level window, such as a dialog box that is owned by a top-level window.

Functional Tester supports some instances of nesting of objects from different domains. That means you can test an object of one domain that is nested inside an object of another domain, and Functional Tester will accurately understand the objects and their domains. If a nesting of one domain within another is not supported, Functional Tester will model the objects consistently but may not accurately understand the domain for the nested objects. For example, Functional Tester does not support the nesting of a .Net control within a Windows application. In this case, Functional Tester is likely to see the .Net controls as if they were Windows controls (because .Net controls are often implemented using the underlying mechanisms of Window controls). Another example is a Windows-based dialog that appears on top of a Java™ application. In this case, the Java domain does not understand the windows dialogs, or even acknowledge that they exist. And since by default Functional Tester does not dynamically enable a Java application as if it were a Windows application, there is no Windows domain in that process. So in this instance, the dialogs are not testable objects without scripting.

The following list describes the cases of nested domains that are supported.

HTML - ActiveX as child -- This is an HTML page that contains ActiveX controls.

HTML - Windows Owned -- Some common dialogs displayed by Internet Explorer will appear as Windows domain objects.

.Net - ActiveX as child -- This is a .Net Winforms application that utilizes legacy ActiveX controls.

.Net - HTML as child -- This is a .Net WinForms application that utilizes an embedded Internet Explorer browser control.

.Net - HTML as owned -- This is .Net WinForms application that utilizes an embedded Internet Explorer browser control that in turn displays a dialog composed of HTML (shown by calling ShowModalDialog in JavaScript).

.Net - Windows as owned -- This a .Net WinForms application that displays some form of non-WinForm dialog. For example, when a .Net application displays a common dialog (File Open, Print, etc.) or messagebox.

Java - HTML as child -- This a Java SWT application that utilizes an embedded Internet Explorer browser control.

Java - HTML as owned -- This a Java SWT application that utilizes an embedded Internet Explorer browser control that in turn displays a dialog composed of HTML (shown by calling ShowModalDialog in JavaScript).

Windows - HTML as child -- This is a generic Windows application (possibly VB 6.0 or MFC) that utilizes an embedded Internet Explorer browser control.

Windows - HTML as owned -- This is a generic windows application (possibly VB 6.0 or MFC) that utilizes an embedded Internet Explorer browser control that in turn displays a dialog composed of HTML (shown by calling ShowModalDialog in JavaScript).

Windows -.Net as child – This is a generic Windows application (possibly VB 6.0 or MFC) that embeds .Net WinForm controls.

Nested domains in the object map

You can see that objects are of different test domains by looking at the object map. In the object map, each object is listed by its object type and domain type. For example, the following object:

Java: Button: close-order: javax.swing.JButton

is a Java button that is a javax.swing.JButton object type. The "Java:" prefix shows that the object is in the Java test domain. The test domain of every object is always the first thing shown on each object listed in the map, as shown in the example above. If a child object has a different domain than the parent object, you will see two different prefixes in their entries in the object map.

Feedback