Microsoft Knowledge Base

- Microsoft Test for Windows, versions 2.0 and 3.0

SUMMARY

Microsoft Test has functions you can use to interact with standard controls that are generally used by the Windows applications you are testing. The standard controls have class names like Edit, Button, Static, ComboBox, ListBox, and ScrollBar.

Microsoft Windows also allows applications to have non-standard controls. Applications can create custom controls to perform tasks not supported by predefined controls. This article discusses some of the issues related to non-standard (custom) controls.

MORE INFORMATION

Three Ways to Create Custom Controls

Here are some of the ways to create custom controls:

• Use owner-drawn buttons, list boxes, and combo boxes.
• Subclass an existing control-window class.
• Register and implement from scratch an application-defined window class.

An application can designate list boxes, combo boxes, and buttons as owner- drawn controls by creating them with the appropriate style. When a control has the owner-drawn style, Windows handles the user's interaction with the control as usual -- performing such tasks as detecting when a user has clicked a button and notifying the button's owner of the event. However, because the control is owner-drawn, the parent window of the control is responsible for the visual appearance of the control.

Subclassing an existing control is another way to create a custom control. The subclass procedure can alter selected behaviors of the control by processing those messages that affect the selected behaviors. All other messages pass to the original window procedure for the control. For example, an application can display a small bitmap next to the text in a read-only, single-line edit control by subclassing the control and processing the WM_PAINT message.

An application can create custom controls by registering an application- defined window class and specifying the name of the window class in the CreateWindow or CreateWindowEx function or in the dialog box template. The process for registering an application-defined window class for a custom control is the same as for registering a class for an ordinary window. Each class must have a unique name, a corresponding window procedure, and other information.

Control-Like Objects

Applications can also have "painted" controls, which are really not controls and do not have any classname or any other characteristics of a window. Even though it looks like a control (for example, it might look like a button) and behaves like a control, you can't send a Windows message to it because it is not a true control. For example, in a Microsoft Test script, you might send a message using the WButtonClk functions. But these messages can't be sent to painted controls, so you need to use the DoKeys, Quekeys, or QuemouseClk functions to interact with control-like "painted" object. FoxPro and Microsoft Access use a lot of these control-like objects.

How to Determine the Type of a Control

You can determine the type of a control in many different ways. You can ask the application designer to document and inform the test engineer of any custom controls in the application. You can use the Utility that comes with Microsoft Test to find the class name of the control or a window. You can select "Tools - Window Info.. " Menu from Microsoft Test to run the above mentioned utility. You can use the SPY++ or SPY products that ship with Visual C/C++ version 2.0 or Visual C/C++ version 1.51 to find the class name of a control.

New Funtions in Microsoft Test Version 3.0

In Microsoft Test version 3.0, you'll find some new functions you can use to interact with custom controls. Here are a few of the more useful ones:

• Use WCustomClick to click in the center of the client area of a control or window.
• Use WCustomDblClick to double-click in the center of the client area of a control or window.
• Use WCustomClickAt to clicks at a point within a control's client area.
• Use WCustomEnabled to check the enabled state of a specific custom control.
• Use WCustomExists to check whether a specific custom control exists.
• Use WCustomFocus to check whether a specific custom control has the focus.

When You Can't Use a Microsoft Test Function to Interact with a Control

It is not always possible to use Microsoft Test functions to interact with the custom controls in the application. When you can't use a function, you can work around the problem in creative ways. For example, Visual Basic has a control called the Grid control. Even though there is no direct way to retrieve the text displayed by the control, if the application that uses this control has a feature to select and copy the text to the clipboard, you can use the CLIPBOARD$ command from Microsoft Test to retrieve the text.

Occasionally a control may have a non-standard class name. To use Test Control procedures on a control that has a non-standard class name, you need to use a special procedure. Each group of Test Control functions has a procedure that enables you to set the class name for which the function should search. For Buttons, use the ButtonSetClass function, and for edit controls, use WEditSetClass. This method will work only if the controls are going to process the standard control messages such as LB_XXXXXX (For List box) or CB_XXXXX (For ComboBox).

REFERENCES

Microsoft Test 3.0 User's Guide, "Working with custom controls" section of Chapter 3, Using Microsoft Test, page 52.

Microsoft Test 2.0 User's Guide, "Setting the class of Non-Standard Controls" section of Chapter 3, Microsoft Test Applications, page 46-47.

Programmer's Reference, Volume 3: Messages, Structures, and Macros of Microsoft Windows Software Development Kit