Wizlink Migration Manual
Wizlink scenarios from software version 2.0.0 are not compatible with scenarios created in earlier software versions. The new scenario cannot be opened in the old software and the old scenario in the new software version. The Wizlink Migration Tool application has been created, which allows you to migrate a scenario created in Wizlink Designer versions earlier than 2.0.0 to the format supported from version 2.0.0. Automatic migration will take place in the majority of cases and you can immediately export such a scenario to the new format.
In some cases however the user may be asked to perform certain actions that cannot be performed automatically. These actions will have to be taken in the occurrence of phenomena referred to as Problems and Warnings. The Problems must be resolved to complete the migration, while Warnings are indications for the user that a given part of the scenario may behave slightly different than before and should be looked at more carefully.
The rest of this document describes the Problems and Warnings you may encounter during migration, and how to resolve them. The term migration means opening an older version scenario in the Wizlink Migration Tool application, solving problems if any, and exporting the changed scenario to the new version.
Problems
There may be two problems during scenarios migrating, that require user action. Both are related to the changes that have occurred in the GUI controls. These problems are: duplicated controls and orphaned controls.
Controls' duplicates
As of version 2.0.0 each control contains a unique ID that is used to uniquely identify the control. Previously, controls were not uniquely identified, which could lead to duplicates.
We will consider this problem on the example below:
There are two controls named data. However, these controls are placed in two different groups.
It is pure coincidence that there are identical controls on two different web pages (and unfortunately the script writer did not care to distinguish them by giving them different names).
In our sample scenario the data control appears in two places. However, it is not clear whether both Set Text refer to the same website or maybe two different ones. It is not clear also what controls was used: whether in both activities was used the same control (which one? from Web page 1 or Web page 2 group?) or one in first Set Text and the other one in second Set Text (but which one where?).
When you open such a scenario in the migration tool, you will be informed that there are duplicates of controls and this is a problem that must be resolved to complete the migration. It can be solved in two ways:
1. If both incriminated controls are from the same application/same web page, they are actually replicas. In this case you should remove the redundant control so that only one remains. Open context menu clicking on one of the data controls with the right button, and then select the Remove option and confirm this operation.
2. In the case that they are separate controls from different applications/web pages that accidentally have the same name and different properties and you want to keep both of them as separate controls, proceed as follows:
-
- first - rename the controls. Open context menu clicking on one of the data control with the right button, then select the Rename option, change the name and confirm this operation. In our case we can differentiate them into data web 1 and data web 2 for example.
- second - the renaming will not be applied to the controls in scenario automatically because the program does not know which activity is using which control. So you should assign the right controls from the panel on the left to the right activities (simply drag and drop them on the activities). When all occurrences of data control in a scenario are overwritten by renamed controls - the problem is solved.
Orphaned controls
In Wizlink Designer it is possible to copy an activity or an entire part of a scenario and paste it into another scenario. In older versions of Wizlink Designer (v.1.x) if the pasted activity contains a control that was not present in this scenario before, then the scenario will have an activity with a control that is not present in the Virtual GUI controls panel. We call such a control an orphaned control. (As of version 2.0.0 such situation is unacceptable. In versions 2.x pasting an activity with a control that is not in this scenario will automatically add it to the control panel).
In the sample scenario below you can see that there is only one control named Options in the Controls panel that comes from IrfanView. But there is an activity in a scenario that contains a View control that is not in the Controls panel because that activity was copied from another scenario.
The following ilustration shows controls panel in the Wizlink Migration Tool after opening this scenario.
The View control has been placed in a group named Orphaned. In our example the View control comes from the same application as the Options control. To solve a problem of orphaned control one should assign it to this application, simply by dragging the View control to the IrfanView group. Dragging all controls from the Orphaned group to other groups solves the problem of orphaned controls.
Wizlink Migration Tool created the special group No app info at the same time. There will go controls coming from another applications for which no corresponding folder has been created. Such a control will not contain information about the application it comes from and in the future it will not be possible to drag it onto activities such as: Run Browser, Run Application, Run Terminal.
Warnings
During the migration of a scenario, four types of Warning may appear in the Wizlink Migration Tool. Resolving the Warnings issues is not required to export the scenario to the new format and start using it in the new version of Wizlink. On the other hand the warnings indicate that a situation has been detected in which the scenario may function slightly differently after migration. And to preserve the previous behavior, you have to make some changes to the scenario.
Activities that return a result using the Result parameter
The activities File/Folder Exists, Yes/No Box, Check Existence, Check Pattern, Check Prompt are activities that return true/false information. For example, File/Folder Exists returns the information whether the file/folder exists in the location indicated by the given path in the file system. These activities returned this information through the Result output parameter. For other activities, this parameter is used to return information whether the activity was successful or an error occurred during execution. In Wizlink ver.1.x File/Folder Exists will return Result = false when the file does not exist or when an error occurred while executing the activity. If the option Alternative scenario if failed is checked, then when Result = false, the scenario will be interrupted and the alternative scenario will be executed.
As of version 2.0.0, the activity behavior is made more consistent. From now on, these aforementioned activities will return a result through the new Answer parameter, and Result will be false only if an error occurred while performing the activity. So if the file does not exist, File/Folder Exists will return Answer = false and Result = true.
If there was one of the aforementioned activities in the scenario before migration and it had the Alternative scenario if failed option selected (it was expected that with a negative result of the activity, the whole scenario will go to the alternative scenario and its operation will be terminated), then after migration such scenario will not be terminated (because the negative result of the activity will be in the Answer parameter, while the activity itself will have Result = true).
If the Wizlink Migration Tool detects such a situation, a Warning will appear and the text !!! will be entered in the Result field of such activity to draw your attention.
Starting from version 2.0.0 it is recommended to use the aforementioned activities as follows: the result of the activity (Answer output argument) is assigned to a Boolean variable. Then, using the If activity, another action is performed depending on the value of the variable.
Result Code Changes
Most of the activity has an output argument of Result Code that contains the activity error code. If the activity was successful, it is equal to 0. If an error occurred during execution, it contains a value greater than 0, which may store information about what error occurred. As of version 2.0.0, the values of the error codes and their meanings have changed. Some activities return more or less error codes than before, and most codes have changed values. If error codes were used in your scenario, please ensure during migration that they are used in accordance with the current ones provided in the Wizlink documentation.
If the migration tool detects that a variable is assigned to the Result Code, it will warn you that the scenario is probably using error code values that have changed.
Scenario Invoker activity
Be sure to migrate your subscenarios first, before migrating the actual scenario.
Take Screenshot activity
Fullscreenshot file name is no longer returned as out argument. This file is now always saved as FullScreen.png.
