Nested domains support
HCL OneTest™ UI 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.
HCL OneTest™ UI 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 HCL OneTest™ UI will accurately understand the objects and their domains. If a nesting of one domain within another is not supported, HCL OneTest™ UI will model the objects consistently but may not accurately understand the domain for the nested objects. For example, HCL OneTest™ UI does not support the nesting of a .Net control within a Windows® application. In this case, HCL OneTest™ UI 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 HCL OneTest™ UI 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.