Serious error when you debug a macro

[FS]

I downloaded the M Scheduler 7.1.13e and installed it.

When I tryed to debug a macro (using F8) and the step was SetFocus> I got the following error message:

Access violation at address 00401D26 in module 'MSCHED.EXE'. Write of address 0D302C35

Another times it appears a error message like this:

Cannot create file C:\PROGRAM FILES\MJT NET LTD\MACRO SCHEDULER\_debug.dbg

What can I do?

[armsys]

FS,

Is your script editor closed when the error occur?

[FS]

No. The M Sched. Editor is open and remain open when the error happens.

Regards.

[armsys]

When debugging in Macro Scheduler Editor, it creates __debug.dbg, which could be locked under abnormal circumstance. Completely quit Macro Scheduler from the System Tray. Delete C:\Program Files\MJT Net Ltd\Macro Scheduler\_debug.dbg. Run Macro Scheduler again. The debugger should run smoothly.

Please keep us posted about your troubleshooting. Happy MS scripting.

[FS]

Thank you for you response.
Now I know what to do about the "__debug.dbg" file.

But the other problema stay. When debugging and arrive to a SetFocus instruction, it appears the other error message.

[armsys]

Hi FS,

In the absence of your original script, any endeavor to guess about your SetFocus> anomaly will be futile.

[FS]

The script is this:


ExecuteFile>c:\windows\escritorio\pantalla.lnk
WaitWindowOpen>Pantall*
SetFocus>Pantall*
Press CTRL
Press Tab *5
Release CTRL
Press Tab
Press Left
Press Enter *2
WaitWindowOpen>Configuración del monito*
Press Alt
Send Character/Text>s
Release Alt


When debugging and arrive to SetFocus instruction, then I got the error message.

[armsys]

FS,

Thanks for posting your source script.

1. Are you sure that SetFocus>Pantall* causes you trouble?
2. Are you sure Macro Scheduler support the following comamnds:

Press Tab *5
Press Enter *2

3. Could you tell us more about the details of the error you enocunter?
4. Does it ususally take a longer time to open the application associated with pantalla.lnk?

5. Please allow Windows some time to process your keystrokes. In the absence any WAIT events, Macro Scheduler bursts all keystrokes (scan code values) into the keyboard buffer. For an example of pressing Ctrl-Tab, Windows often misses the CTRL key in the following code:
Press CTRL
Press TAB

The following code could improve the likelihood of success:
Press CTRL
Wait>0.2
Press TAB

Please keep us posted your troublesome progress. Wish a Merry Christmas and a Happy New Year.

[support]

Hi,

Does this problem only occur during debug? Does it work ok when run normally?

Do you have 'Refocus Windows' checked or unchecked? If it is off don't forget that key sends after the setfocus will most likely land on the Macro Scheduler editor (or someplace else unintended) because the debugger doesn't refocus the SetFocus-ed window - and that could be the cause of the problem.

Ensure 'Refocus Windows' is checked on and see what happens then.

Another thing worth doing is to set WF_TYPE to 0 to avoid the SetFocus line picking up a child window, or to 2 for only visible windows - just on the off chance that the problem is that the SetFocus line is picking some child/hidden window up when run from the debugger that doesn't like it:

Let>WF_TYPE=0
SetFocus>....

It is seldom necessary to insert a Wait statement between a Press CTRL and subsequent key sends as Armstrong suggests - I have never had need to do this and find it just makes the script dificult to read. You have also correctly made use of WaitWindowOpen to allow time for the application to become active.

Hopefully we'll get to the bottom of this - thanks for your cooperation!

[armsys]

Hi Support,

Thanks for your clarification.

For inserting Wait> (range from 0.1 to 0.5) command after Press CTRL, I only speak from my experience, which may vary amongst Macro Scheduler users. It helps improve the likelihood of successful repetitions especially during busy background activities.

I almost forget the setting of 'Rocus Windows". Thanks, Support.

Again, from my experience, the SetFocus> error is, by and large, caused by the failure to find the named window defined in SetFocus> command line. That's the only possibility I could think of.

And, FS did mention in his previous post that his script ran smoothly without debugger.

Last but not the least, all technical opinions expressed by Support is official and absolute.

Wish everyone on the forum a Merry Christmas and a Happy New Year.

[FS]

Hi,

The problem occurs just when debugging. Running the macro works fine.

When debugging, "Refocus Windows" is enabled.

When debugging and when running there is only one windows matching "Pantall*".

The error message appears when the debugging arrive to a SetFocus instruction.

Regards.

Merry Christmas and Happy New Year for everyone.

[armsys]

Thanks for your feedback. I scrutinize your script and experiment some portion of your script again. I fail to identify any syntactical errros.

I was wrong in suspecting the validity of tghe syntax of Press TAB *5. The Commnad Reference (command_ref_7.1.pdf) never mentions the *n parameter. However, the online Help (press F1) manifests this special feature right at the beginning under "Press..." section.

Let's troubleshoot one step at a time:
1. Remark out (by inserting // in the front the command line in question) SetFocus>Pantall*. Do it run successfully with the debugger?

2. Add Wait> 5.

Your script should become:
ExecuteFile>c:\windows\escritorio\pantalla.lnk
WaitWindowOpen>Pantall*
//SetFocus>Pantall*
Wait>5
Press CTRL
Wait>0.2
Press Tab *5
Release CTRL
Press Tab
Press Left
Press Enter *2
WaitWindowOpen>Configuración del monito*
Press Alt
Send Character/Text>s
Release Alt

Pleaes let us know whether the above script can ran smoothly free of error under the debugger's watch. Thanks. Merry Christmas.