Wilko was kind enough to post an updated version of his error handling code.  The original method needed to be updated to handle a

recent change

to the {failstep} variable.  (script at bottom of this post)

For those that are interested in our free programs, the popular utility "

WhatChanged

" (#2 in downloads after

TinyTask

) has received an update.  This new version includes performance enhancements.  It also has some minor changes to the interface, including a new progress bar (only used during step #2 - compare snapshot).

    * Version 1.06, typical system scan:  04:15

    * Version 1.07, typical system scan:  03:35  (15% speed improvement)




As with all the free tools, no personalized tech support is provided.

Note:  A few users have commented about the log files that are created.  These are necessary so that differences can be tracked persistently between reboots, for example, following a software installation that requires multiple PC restarts.

Thank you for testing & verifying the fix.

Fix confirmed.

Thanks!

Hi Wilko,

Your request has been added to version 7.78 and greater.  The {failstep} system variable will no longer be set if the Failure mode is "Jump to Label."  Your suggestion seemed like a very valid assumption.

As for your second question, both {fail_step} and {failstep} will continue to be supported in the future.

The enhancement mentioned above ("when the user enters a complete string rather than a character list, allow string matching") has been added to version 7.78 and greater. 

As sean444 confirmed above, the SUBSTITUTE method also provides similar functionality.

I have a small routine that does something like this (also see code below):
Label  DeleteFolder
Click on Image
Click on Delete button
If not image is still visible.  On fail > Jump to label DeleteFolder (in case another instance exists it should also be deleted)
Exit run {fail_step}

My problem is the jump to label action. If it fails it sets the {fail_step} variable.
I think that in case Jump to label is selected {fail_step} should not be set because this is an anticipated failure (same as ignore/continue).

Another small thing: In vTask I select {fail_step} but in the manual there is only {failstep}. Both work fine but my old scripts all have {failstep} and the new ones {fail_step}. This was confusing me a bit (I thought it was the cause of this behaviour). Is it possible to 'auto-update/fix' scripts (on save) or maybe add something to the manual.

VXM Script:   (Copy and Paste into vTask)

<step>
	<action>Label</action>
	<text>DeleteFolder</text>
</step>
<step>
	<action>Click on Image</action>
	<text>RemoveThis.bmp</text>
	<options>Snap to Position,Masked</options>
	<value1>8</value1>
	<timeout>10</timeout>
	<indents>1</indents>
	<onfail value="" image="0" log="1">Stop Silently</onfail>
</step>
<step>
	<action>Click on Image</action>
	<text>Delete.bmp</text>
	<options>Snap to Position,Masked</options>
	<value1>8</value1>
	<timeout>10</timeout>
	<indents>1</indents>
	<onfail value="" image="0" log="1">Stop Silently</onfail>
</step>
<step>
	<action>IF Image is Visible</action>
	<text>RemoveThis.bmp</text>
	<options>Quick Check,IF NOT</options>
	<value1>16</value1>
	<indents>1</indents>
	<onfail value="DeleteFolder" image="0" log="0">Jump to Label</onfail>
</step>
<step>
	<action>Exit Run</action>
	<text>{fail_step}</text>
</step> 

Thanks!  The SUBSTITUTE method works great.

UPDATE: Working on a enhancement for the LTRIM function: when the user enters a complete string rather than a character list, allow string matching.  Sample:



This will do what the user intended in post #1.  This enhancement will be accomplished by adding a check for duplicated characters (such as multiple spaces) in the target string, and then only removing the matching front string, rather than using target as a character list.

Another solution is to use the

SUBSTITUTE

function, which will provide user's desired functionality for all examples provided in first post.

Thank you for the accurate report, and for providing samples to duplicate the problem.  This LTRIM bug has now been confirmed, and is being worked on today.  An update to the program will be ready shortly.  Apologies for any inconvenience this has caused.


Edited:


The way LTRIM works is to remove all occurrences of the characters provided.  For example, if you want to remove all whitespace from the front of a string, you would use:



In other words, the order of the characters does not matter (it's not a string matching function, as you are using it).  Emphasis on the word TRIM, indicating that it removes individual characters, until no more match your list.

LTRIM works this way in other languages as well, such as

PHP

.  So vTask is working correctly.



[To Do: provide an alternative suggestion.  -Moderator.]