We can use the "statusbar_get_text("Status Bar",0,text);" function "text" variable contains the status bar statement. or web_cursor_to_link ( link, x, y ); link The name of the link. x,y The x- and y-coordinates of the mouse pointer when moved to a link, relative to the upper left corner of the link.

DO NOT use BitMap or GUI Checkpoints for dynamic verification. These checkpoints are purely for static verifications. There are ofcourse, work-arounds, but mostly not worth the effort.

set_window("Name of the window"); obj_check_info("Name of the object ","focused",0ut_value); check for out_value & proceed further

If WR is not learning sub-items then the easy way id to add manually those sub items in to GUI map.. of course you need to study the menu description and always add the PARENT menu name for that particular sub-menu.

Several web page windows with similar html names they all end in or contain " MyCompany" The GUI Map has saved the following physical description for one of these windows: { class: window, html_name: "Dynamic Name | MyCompany" MSW_class: html_frame } The "Dynamic Name " part of the html name changes with the different pages. Replace: { class: window, html_name: "!.*| MyCompany" MSW_class: html_frame } Regular expressions in GUI maps always begin with "!".

> Use get-time to get the PC system time in seconds since 01/01/1970 > Subtract 86400 (no seconds in a day) from it > Use time_str to convert the result into a date format > If format of returned date is not correct use string manipulations to get the format you require > Insert the date into your application Alternatively we could try the following : > In an Excel datasheet create a column with an appropriate name, and in the first cell of the column use the excel formula. > Format the cell to give us the required date format. > Use the ddt : functions to read the date from the excel datasheet. > Insert the reteived date into our application .

public function IsValidEMAIL(in strText) { auto aryEmail[], aryEmail2[], n; n = split(strText, aryEmail, "@"); if (n != 2) return FALSE; # Ensure the string "@MyISP.Com" does not pass. if (!length(aryEmail[1])) return FALSE; n = split(aryEmail[2], aryEmail2, "."); if (n < 2) return FALSE; # Ensure the string "Recipient@." does not pass. if (!(length(aryEmai2[1]) * length(aryEmai2[1]))) return FALSE; return TRUE; }

Suppose we are running a batch test on an unstable version of our application. If our application crashes, We want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch. The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. We implement this function to respond to the unexpected error in the way that meets our specific testing needs. Once we have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.

A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be Default actions, WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box. > User-defined handler : If we prefer, specify the name of our own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run. WinRunner enables we to handle the following types of exceptions : > Pop-up exceptions : Instruct WinRunner to detect and handle the appearance of a specific window. > TSL exceptions : Instruct WinRunner to detect and handle TSL functions that return a specific error code. > Object exceptions : Instruct WinRunner to detect and handle a change in a property for a specific GUI object. > Web exceptions : When the WebTest add-in is loaded, we can instruct WinRunner to handle unexpected events and errors that occur in our Web site during a test run.