background image
<< Porting Tests - Supporting extra controls | Porting Tests - Creating a class that maps to several SilkTest classes >>
Porting Tests - Supporting different implementations of the same control
<< Porting Tests - Supporting extra controls | Porting Tests - Creating a class that maps to several SilkTest classes >>
274
User's Guide
13 P
ORTING
T
ESTS
TO
O
THER
GUI
S
Supporting different implementations of the same control
Dialog on Windows
The Windows GUI allows an end user to enter the file name to be opened as a
path name in a text field; the Macintosh GUI does not. Therefore, the
following two declarations are recorded under Windows, but not under
Macintosh:
StaticText FileNameText
tag "File Name:"
TextField FileName1
tag "File Name:"
When merging the window declarations for the two GUIs, you need to
preface these declarations with the msw GUI specifier:
msw StaticText FileNameText
tag "File Name:"
msw TextField FileName1
tag "File Name:"
Dialog on Macintosh
Similarly, the Macintosh version of the dialog has two pushbuttons which do
not appear on the Windows version. The first pushbutton allows the user to
eject a floppy disk from the disk drive. The second pushbutton allows the user
to navigate to the desktop directory. Therefore, the following two
declarations are recorded under Macintosh, but not under Windows:
PushButton Eject
tag "Eject"
PushButton Desktop
tag "Desktop"
So, when merging the window declarations for the two GUIs, you need to
preface these declarations with the mac GUI specifier:
mac PushButton Eject
tag "Eject"
mac PushButton Desktop
tag "Desktop"
Supporting different implementations of the same control
One logical control
can have two
implementations
Consider the case where the same logical control in your application is
implemented using different classes on different GUIs:
If the kinds of actions you can perform against the object classes are
similar, and if SilkTest uses the same method names for the actions, then
you do not have a portability problem to address.