All activity done by user during recording session is translated into
high-level actions. The Rapise recorder tries to interpret user actions in
straight and simple way as much as possible. In some cases it is enough, but in
other cases additional actions are required.
For example consider the editable combo-box:
Whenever the value is changed depending on exactly how the user interacts
with the control, one of the following actions may be recorded:
i.e. combo box text is changed
i.e. selected item is changed
These actions will re-produce the appropriate user behavior. The object
value will change once either of these are executed. But a specific application
may be sensitive to which specific event is triggered. That is why it may be
required to change the recorded sequence to match the expected event.
The target application may have different responses for the various
different events. For example, the programmer may put the editable Combo Box on
a form but only expect the end-user to select item. The screenshot below
We have "Account:" field set to some value. This is a prerequisite
for other fields to become 'enabled' i.e. to allow user to set "Update
Type", and "Account Holder". In this case you may see that
account number is typed into the field but other fields left disabled.
The explanation of this side effect is simple, the programmer didn't expect
the combo box text to be changed manually and let the program to wait for
"On Selection Changed". In this case we didn't change the selection,
we just changed control value text.
So once we do the selection of the same value using the combo box dropdown
the required response happens and the application enables the other input
fields to become available:
One may consider using either:
or their combination after the application is recorded. This
may help to produce required application responses. Of course a real
application should be able to handle all possible user interactions so these
situations may highlight user interface issues in the application itself!