bugs in looping

[GErickson]

I am attempting to evaluate this product for my company's use, as it seemed to have a good set of features, but I have run up against some pretty major bugs after using it for 3 days that are preventing me from doing what I need to do.

The following simple script loops forever, even though when stepping through it with the watch window open, the until test (LoopCt==LoopStopNum) is clearly seen to be met (99==99) at the end of the second pass.

Also, it cannot be stopped with Shift-Esc nor Ctrl-B, possibly because the modal message dialog is open most of the time.

Once LoopCt>LoopStopNum, trying to use Quit from the toolbar menu sends the macro into some mode where the modal message dialogs keep popping up but don't wait for input. I had to use task manager to kill the Macro Scheduler program. If the modal message is commented out, it will take over your computer to the extent not even Task Manager can get control; I had to use shutdown from an RDC (Remote Desktop Connection).

One other oddity: when single-stepping, after a MessageModal command, the focus stops reverting back to the "action" window that had the focus just before the message dialog was popped up before each command is executed. This breaks the macro. Workaround - add a SetFocus command after every Message or MessageModal command.

I am using the latest version of Macro Scheduler. I experienced these problems under Windows NT 4.0 TSE and most of them under Window XP Home, as well.


// C:\Program Files\Macro Scheduler\test2b.scp
// this macro demonstrates a bug - loop never ends even though
// LoopCt==LoopStopNum after second pass;
// also, Shift-Esc and Ctrl-B will not stop it;
// you need a Notepad file open named TestDoc.txt
// the easiest way to stop it is to close the TestDoc.txt window

Let>LoopStartNum=97
Let>LoopEndNum=98

Let>VAREXPLICIT=1
Let>WW_TIMEOUT=2
Let>WF_TYPE=2 - Visible Windows Only
CapsOff

Let>LoopCt=%LoopStartNum%
Let>LoopStopNum=%LoopEndNum%+1
Repeat>LoopCt
SetFocus>TestDoc.txt - Notepad
WaitWindowOpen>TestDoc.txt - Notepad
If>%WW_RESULT%=FALSE,WindowError
Send>%LoopCt%
Press Enter
Let>LoopCt=%LoopCt%+1
// warning - if you remove MessageModal on next line or SetFocus at
// beginning of loop, this macro may be very difficult to stop
MessageModal>LoopCt=%LoopCt%
Until>LoopCt,LoopStopNum
MessageModal>Finished
goto>End

Label>WindowError
MessageModal>Window didn't open.
Label>End

[Bob Hansen]

Hello GErickson........you've got it. Two minor changes. Also suggest you change the title of this subject to eliminate BUG, it is just a syntax error. Don't want to scare off new users thinking this is a buggy product. That is not the case.

This code runs fine on WIN98SE system. Changes are in bold red Comments in bold blue.

// C:\Program Files\Macro Scheduler\test2b.scp
// this macro demonstrates a bug - loop never ends even though
// LoopCt==LoopStopNum after second pass;
// also, Shift-Esc and Ctrl-B will not stop it;
// you need a Notepad file open named TestDoc.txt
// the easiest way to stop it is to close the TestDoc.txt window

Let>LoopStartNum=97
Let>LoopEndNum=98

//Change VAREXPLICIT to default value of 0
Let>VAREXPLICIT=0
Let>WW_TIMEOUT=2
//Cannot have comments at end of line, remove explanation in bold red
Let>WF_TYPE=2 - Visible Windows Only
CapsOff

Let>LoopCt=%LoopStartNum%
Let>LoopStopNum=%LoopEndNum%+1
Repeat>LoopCt
SetFocus>TestDoc.txt - Notepad
WaitWindowOpen>TestDoc.txt - Notepad
If>%WW_RESULT%=FALSE,WindowError
Send>%LoopCt%
Press Enter
Let>LoopCt=%LoopCt%+1
// warning - if you remove MessageModal on next line or SetFocus at
// beginning of loop, this macro may be very difficult to stop
//When doing single step in debug mode, you should press on OK to make this window go away and proceed.
//Must be quick, because focus will return to debug window.
MessageModal>LoopCt=%LoopCt%
//Must click on OK when single stepping thru process.
//Put % around LoopStopNum
Until>LoopCt,%LoopStopNum%
MessageModal>Finished
goto>End

Label>WindowError
MessageModal>Window didn't open.
Label>End

Here is the section from Help on VAREXPLICIT:

You can tell Macro Scheduler only to resolve variables that are contained within % symbols and to leave anything else as literals by setting the VAREXPLICIT variable to 1:

Let>VAREXPLICIT=1

The default is 0 and will cause default behaviour as described above - i.e. Macro Scheduler will look at any parameter to see if it is a variable. If a variable with that name exists, the value assigned to that variable is used, otherwise just that literal value is used. Setting VAREXPLICIT to 1 stops this behaviour and tells Macro Scheduler only to resolve a variable if it is contained within % symbols. E.g.

Let>VAREXPLICIT=1
Let>Name=Fred
Send>Name
Send>%Name%

In this case the first Send> command will send the literal 'Name' and the second would send the value 'Fred'. In the following example, which is the default behaviour, both Send> commands would send the value 'Fred':

Let>VAREXPLICIT=0
Let>Name=Fred
Send>Name
Send>%Name%

As a matter of practice, I usually accept the default value of 0, make no entry in the script, and always surround my variables: %variable% when using the value vs. the name. And I almost always use the %variable% when using IF type of statements so I can read the log and see what the value actually was when the line was executed.

Enough testing already, go for it! Macro Scheduler will solve your problems.

[GErickson]

Thank you very much for the reply. Changing VAREXPLICIT back to the default did indeed cause it to work. Not what I expected from the documentation. Are you telling me VAREXPLICIT=1 does not work as documented?

For safe programming, one wants to control when parameters or tokens are interpreted as variables. Otherwise, with VAREXPLICIT=0, I would expect the following:
Let>a=1
MessageModal>a is %a%
to output "1 is 1", since both a's are parameters to the MessageModel command, and the documentation clearly states "Macro Scheduler will look at any parameter to see if it is a variable. If a variable with that name exists, the value assigned to that variable is used, otherwise just that literal value is used".

Or is there an undocumented exception that within parameters to output commands, variables are only expanded if they are within %%? Or does parameter mean something different in MS documentation than the usual meaning of "argument to a command"? Or is "a is %a%" interpreted as one string parameter with different rules instead of 3 parameters separated by white space?

Also, with VAREXPLICIT=0, why doesn't Let>a=%a%+1 try to use the value of a on both the left and right side of the = sign. Or is there another undocumented exception when the parameter is an equation and the variable is an lvalue (on the left side of the =) in the equation?

Regarding end of line comments, I discovered earlier they break the command. But I copied the "Let>WF_TYPE=2 - Visible Windows Only" directly from the documentation, and the editor did not interpret the " - Visible Windows Only" as a comment and color it differently.

It's these type of non-consistent, or at best undocumented behaviors that make me worry that this program isn't quite ready for me to stake important processes on.

By the way, what is your connection to Macro Scheduler? Do you work for them or are you an experienced user that's already banged your head up against stuff like this?

[Guest]

I'm working with MSched since 3 years. Running a part of the provisioning process for a world leading telco in one of its main markets 24/7/365 (volume some mil € of revenue). IMHO, that's not too bad for a shareware with a reasonable price.

As I know Bob is a user, the backbone of the forum, and unbribable.
If a bug is a bug he will point it out!

[Bob Hansen]

Hello GErickson, glad that worked out for you.

Re my non-association with Macro Scheduler: I am just a very satisfied user. Don't remember how many years I have been using Macro Schedluer, but could not work without it. I have set up many of my clients with registered copies. Success in all Windows OS and Novell environments.

I have reported bugs in the past. I have made many enhancement requests. I have seen many requests implemented. Others may never happen, but I have been very happy with response to requests.

I learn something new every day here at this forum. The users are very willing to share ideas and are non-critical of anyone, a really nice place to get support. Macro Scheduler personnel do participate in the forums and are very responsive to users' issues. Marcus is outstanding!

When you combine the Macro Scheduler commands, especially Execute> and Run Program> to access OS commands, built it vb script. scheduling, and logging, debugging, etc. then you really become challenged in trying to find something you cannot automate. Recent addition of Dialog has really rounded out the package.

Like any program, there will be a few tweaks that you may have to learn, but overall I cannot say enougt good things about this product. Again, I am an independant user with no relationship to Macro Scheduler.

Hope to see you back again with more challenges for us to pick away at.