Dialog Command Storage Demystified

Dialog Command Storage Demystified

Introduction

A primary goal in designing the Silk Performer web browser-driven load-testing feature set (BDLT) was to keep the API as simple and self-explanatory as possible. While the goal of simplicity was met by the design of the BDLT API, aspects of the API responsible for handling dialog boxes are not quite as easy to understand. This article therefore explains how to work with the dialog command storage, the basic component of BDLT dialog box handling.

Dialog boxes

The term dialog box is used in this article to refer to modal child windows of an Internet Explorer browser window. With BDLT, such dialog boxes typically occur when JavaScript code is executed by the browser and the methods alert(…), prompt(…), or confirm(…) are used.

Note: Handling of dialog boxes opened by JavaScript methods showModalDialog(…) and showModelessDialog(…), so called HTML dialogs, is not covered in this article.

Default handling of dialog boxes

When replaying a BDLT script and a dialog box is about to be displayed, the default handling of the replay engine suppresses the appearance of the dialog box by intercepting its creation and forcing the dialog box to close immediately. In this process, the dialog box does not appear and the warning message “BrowserEngine: 41 - Dialogs remained open. Tried to close them automatically” is displayed to highlight the event.

As long as a dialog box is shown for informational purposes only, for example JavaScript alert(…), suppressing a dialog box does not harm automated replay. However, as soon as the user is prompted for input, for example to click a button or enter data into a text field, replay will most likely fail due to the missing user data that could not be provided because the dialog box was suppressed.

User-defined handling of dialogs boxes

To define the replay behavior for dialog boxes, the replay engine must be prepared with dialog handling command items (DHCIs). Dialog handling command items consist of the following:

  • The title of the dialog box that specifies the context for the DHCI. When intercepting a dialog box creation, the internal title of the dialog box may differ from the title used once the dialog box is visible. BDLT uses the title of the dialog box at the time of creation.
  • An action that should be performed on the dialog box, as defined by the API call type and any parameters passed in addition to the dialog box’s title.

Preparation of the replay engine must be performed before the API call that triggers the dialog box (BrowserDlgSet*).

When appropriate DHCIs are available for a dialog box that is to be displayed, the replay engine applies the commands and replay is successful.

As long as you create your scripts using the Silk Performer Recorder, the sequence of generated API calls should be correct, including those required for the preparation of the replay engine to handle dialog boxes. When manual scripting of preparation API calls is necessary, basic knowledge of the dialog command storage is required.

Dialog Command Storage

The term dialog command storage sounds complex, but it is nothing more than a list of DHCIs.

The handling of dialogs boxes can be separated into three phases:

  • Preparation of the dialog command storage
  • Application of the dialog command storage
  • Reset of the dialog command storage

To illustrate the actions performed on the dialog command storage during each of these three phases, consider the following example (subsequently referred to in this article as OURSAMPLE):

  1. With Silk Performer installed, start a BDLT recording.
  2. Click the Prompt button on the following page on the Borland demonstration site: http://demo.borland.com/TestSite/common_main.asp#Pop-up
  3. Type a username into the text field on the dialog box.
    Note: This dialog box was issued by JavaScript prompt(…)
  4. Click OK.
  5. Click OK on the subsequent confirmation dialog box.
  6. Stop recording.

The generated script should resemble the following:

As you can see, dialog box handling API calls have been scripted for each phase.

Preparation of dialog command storage is performed by scripting the following two API calls:

  • BrowserDlgSetText
  • BrowserDlgSetButton

Executing these API calls causes a DHCI to be pushed to dialog command storage.

Take a look at OURSAMPLE in the preparation phase:

BrowserDlgSetText("Explorer User Prompt #1", 0, "John Doe");
BrowserDlgSetButton("Explorer User Prompt #1", "OK");

BrowserDlgSetButton("Message from webpage #2", "OK");

Execution of these API calls pushes the following DHCIs into the dialog command storage:

  • DHCI1 { “Explore User Prompt”, SetText, 0, “John Doe” }
  • DHCI2 { “Explore User Prompt”, SetButton, “OK” }
  • DHCI3 { “Message from webpage” , “OK” }

Dialog command storage now holds three DHCIs for the handling of two upcoming dialogs boxes.

Application of the dialog command storage is now performed whenever the creation of a dialog box is detected by the BDLT replay engine during test execution.

Whenever a dialog box is created, the creation is intercepted and the dialog command storage is searched for DHCIs that match the title of the dialog box.

When matching DHCIs are found, the commands are performed in sequence upon the dialog box. Though the dialog box is not yet visible in this phase, all dialog elements are available and working, so applying the DHCIs achieves the same result as if the user were performing the actions on the dialog box.

Once the last matching DHCI is applied to the dialog box, JavaScript and/or BDL script execution continues.

Since DHCIs are executed in the order of their discovery, it is important that the items in the dialog command storage are in the same order as the user would execute them on the visible dialog box. Consider OURSAMPLE: executing the DHCI for the clicking of the OK button before executing the DHCI for the inputting of the text would close the dialog box prematurely and SetText could then not be executed at all.

The order of DHCIs in the dialog command storage is determined by the order of BrowserDlgSet* API calls in the script (see preparation phase).

OURSAMPLE in the application phase:

BrowserClick("//INPUT[@value='Prompt']", BUTTON_Left);

During execution of BrowserClick, the BDLT replay engine detects the creation of a dialog box. The dialog box’s title is determined (“Explore User Prompt” in this case) and the dialog command storage is searched for all DHCIs that are applicable for the upcoming dialog box, which is in its creation state and still not visible.

The following DHCIs are returned:

  • DHCI1 { “Explore User Prompt”, SetText, 0, “John Doe” }
  • DHCI2 { “Explore User Prompt”, SetButton, “OK” }

Applying the first DHCI results in setting the content of the edit control with index 0 to “John Doe”. Applying the second DHCI performs a press action on the button with the caption “OK”.

With “OK” the dialog box is closed, interception of dialog box creation has finished and JavaScript execution continues.

As the web page’s implementation of the click on the Prompt button results in the opening of another dialog box that shows the input (name) of the previous dialog, the BDLT replay engine detects the creation of the second dialog box. Again the creation is intercepted, the title is determined (“Message from web page” in this case) and the dialog command storage, which still contains three DHCIs (applied DHCIs are not deleted), is searched for applicable DHCIs.

One DHCI is returned:

  • DHCI3 { “Message from webpage” , “OK” }

By applying “OK” the dialog box is closed, JavaScript execution continues, and the next API call is executed.

Reset of the dialog command storage is performed by using the following call:

  • BrowserDlgStop

This API call is usually scripted right after the API call that issues the dialog box.

Calling BrowserDlgStop:

  • Resets the content of the dialog command storage by deleting all DHCIs.
  • Closes any open dialog boxes that could not be closed (for example, no appropriate DHCI was located and executed).

As DHCIs are not deleted from the dialog command storage when they are applied, resetting the dialog command storage can only be achieved by calling BrowserDlgStop.

OURSAMPLE:

BrowserDlgStop();

The dialog command storage is reset and all DHCIs are deleted.

Special case: File download dialog boxes

As Internet Explorer handles file downloads through dialog boxes (for example, Save As), BDLT uses the dialog command storage to also manage downloads.

Note: For full information regarding file downloads, please refer to Silk Performer Help.

Preparing the dialog command storage with DHCIs that handle file downloads is achieved using the following calls:

  • BrowserDlgDownload
  • BrowserDlgDownloadCancel

Application of DHCIs is performed once file download has been triggered.

Reset of the dialog command storage is achieved using the following call:

  • BrowserDlgStop

Additionally BrowserDlgStop acts as a synchronization point for the file download procedure. Since file download is triggered asynchronously, BrowserDlgStop waits for download to begin.

If the expected file download starts within the timeout, test execution pauses in BrowserDlgStop until file download is complete. If the dialog command storage contains a DHCI for handling a file download and that download does not start within a specified timeout, BrowserDlgStop will raise an error.

Conclusion

The API for BDLT dialog box handling is easy to work with once you understand how the dialog command storage is used. The key is knowing that the BrowserDlg* API does not lead to  immediate replay actions and only changes the contents of the dialog command storage. For replay to be successful, you must prepare the replay engine with appropriate DHCIs before the API call that triggers the dialog box.

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-03-15 05:18
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.