background image
<< Porting Tests - Supporting different implementations of the same control | Porting Tests - Changing the window declaration of the control >>
Porting Tests - Creating a class that maps to several SilkTest classes
<< Porting Tests - Supporting different implementations of the same control | Porting Tests - Changing the window declaration of the control >>
User's Guide
275
13 P
ORTING
T
ESTS
TO
O
THER
GUI
S
Supporting different implementations of the same control
For example, the methods for the RadioList and PopupList classes have
identical names, because the actions being performed by the methods are
similar. Therefore, if a control in your application is a popup list on one
GUI and a radio list on another, your scripts are already portable.
·
If the two object classes do not have similar methods, or if the methods
have different names, then you need to follow the steps outlined in this
section to port your scripts.
Creating a class that
maps to several
SilkTest classes
Consider the Direction control in the Find dialog of the Text Editor
application, which allows a user to specify the direction (up or down) of
searches. Suppose that this control is implemented as a check box on the
Macintosh, but as a radio list on all other GUIs. As a radio list, the user
selects either the Up or the Down radio button. On the Macintosh, the user
checks the check box to select Up, and leaves the check box unchecked to
select Down.
The first step in solving this portability scenario is to create a new window
class that you will use for the object on all platforms. The class you need to
define, in effect, generalizes several distinct 4Test classes into one logical
class.
To achieve this generalization, you:
·
Derive the new class from the 4Test Control class, since both radio lists
and check boxes derive from this class.
·
Define the class with a GUI-specific tag statement for each platform.
Each tag statement states the actual class of the control on the particular
GUI. This allows SilkTest to know what the actual class on the control
will be at runtime on each of the GUIs.
·
Define generalized methods that use a switch statement to branch to the
4Test code that implements the method on the particular GUI.
Here is the class declaration, which is arbitrarily named DirButton:
// The class is derived from Control
winclass DirButton : Control
tag "[RadioList]"
mac tag "[CheckBox]"
void Select (LISTITEM Item optional)
BOOLEAN bState
switch (GetGUIType ())
case mac
bState = (Item == "Up")
CheckBox (WndTag).SetState (bState)