Adding more resistance to the Wizards and handling the window/object not found and blocked exceptions & more

As you are probably aware at Kryon there are several ways to handle exceptions such as window not found, window blocked, object not found/blocked, etc. These types of exceptions can be handled locally on the step level as well as centrally for all steps, at the end of the wizard.
Although depending on the situation and the Wizard characteristics you may choose to handle such exceptions locally on the step level, however, at some point you may find it time-consuming to handle all similar exceptions on the step level for each and every step.

Let’s think about a Wizard that works with many visual steps on the web or a desktop application that doesn’t have a faster response time. In a similar case, developers may use hardcoded waiting time in addition to the default wait time of the window step at Kryon. However, it is strongly recommended to avoid using hardcoded pauses in the wizard as they tend to make your wizard fail often if the time to load is longer than the hardcoded wait time.

In this article, I am going to talk about wizard resistance, using dynamic waiting times per step level from advanced view, increasing default waiting time from window step as well as handling centrally all similar exceptions for all steps.

Option 1
The first and simplest option that Kryon offers is to increase the default wait time for the window step. By default it is three seconds, however, if the window appears sooner then the wizard continues to the next of the activities. This can be adjusted both per step level from each window as depicted below or from centrally before starting the wizard development/step recording.

For setting this up centrally, you need to navigate to the main page of the Kryon Studio and click on Tools then Application Settings.

As a second option,  you can create some customized fallbacks on the step level, like the example below. In this example, we may have visual steps or any HTML or JS commands that need to be executed only when the object or the window appears/disappears.

The below combination of advanced commands enables the wizard to wait dynamically for the window or object to appear/disappear for executing the advanced command. In such examples, it's recommended to set a higher waiting time. The first reason is that if the page appears faster then the wizard will continue to the next activities and on the other hand we want to have a hard stop at some point if the page is not loading let's say after three minutes. In other words, we don't want the wizard to try over and over but we may want the wizard to try a second time to start from scratch before reporting it as an unsuccessful run, see below screenshot of the wizard.
Based on this solution once the window is found then the wizard will not come to this block called "Window not found". Similar solutions can be inserted in the block of "Window blocked", or "Object not found" etc. Similar solutions can be inserted before any HTML or JS advanced commands, such as to find out if the object is there then execute the relevant set of commands, if not wait some time then try again. This for the purpose of enhancing the Wizard resistance. The wizard is attached to the article, this part can be found on the third step of the Wizard.

Option 3
In the wizard where there are many visual steps or where the wizard works a lot with visual objects then it's recommended to handle all window/object not found, blocked... exceptions centrally at the end of the wizard.
At Kryon Studio, when we use the "Raise Error" option in the case of the above-mentioned exceptions and when the exception appears, the wizard either raises an error and pauses or if you have designed any solution to the respective block at the end of the wizard called "Wizard start/end actions & error handling" then it goes to that respective block and executes your given commands.

In our example, we want that the Bot in the case of the exception to go to the designated place at the end of the Wizard and execute the set of commands which will do the following:

• Check if the Bot reached this step the first time and tries to find the window or the respective object
• If it's the first time that the Bot reached this step and the window or object is not found then it goes to the else decision at the end of the solution, where it concatenates the step number and its waiting time. Afterward, it goes back to the same step.
• If it is not the first time that the Bot reached this step, then it means that the step number and its respective waiting time are in the variable under WindowsNotFound. It means the Bot will check if the step waiting time is not bigger than the TimeOut. If it's not bigger then the Bot will increment the waiting time of this step and will continue trying to find that exact window or object by going back to that exact step.
• If the step window or object waiting time is bigger than the TimeOut, then it will check the value of the SecondTry. If SecondTry is False then the Bot will try to kill the relevant applications and processes to try scratch from the designated step.
• If the Secondtry is True then the Bot will stop trying and will end the wizard unsuccessfully.

• First, the solution concatenates all the step numbers and their waiting times, so the waiting time of step number X will not get confused with the waiting time of step number X+1, which means that each similar step will have the full time under TimeOut variable.
• Second, this solution can be easily duplicated for all similar exceptions such as window not found, window blocked, object not found, and object blocked, etc. by making some minor changes, e.g. changing the main variable name from WindowsNotFound to WindowsBlocked.
• Using this solution will make your wizard more compact and shorter. It will be easier and faster to maintain the exceptions centrally rather than going step by step.