How can I effectively trace the execution of my script?

[SteenJakobsen]

Hi,

How can I effectively trace the execution of my script?

Can I have the Editor window positioned next to the app I’m automating (for example on monitor 2) and have the app constantly in focus (on monitor 1) while the script is executing step by step and by pressing some shortcut key then make the Script step 1 one line a time without the app loosing focus.

I have tried the debug mode using a **Breakpoint** but the switching of focus between the app an the MSEditor confuses the app as the
Loosefocus event is triggered, and also there are timing issues when focus is returned to the MSEditor before the automated app has received all keystrokes.

By having MSEditor on monitor 2 and the app in focus on monitor 1 and then being able to step through the script would be great.
The following debugging keys would be great:
1. Stop and Pause script (I can do that already.. )
2. Step 1 line at a time without the focus switching
3. Continue execution without single stepping until next breakpoint
4. Reenable single stepping so that a breakpoint is not needed.


Any feedback is mostly appreciated.

[gdyvig]

Hi SteenJakobsen,


I don't have a dual monitor setup so I am not sure if your request is possible. It may be that a dual monitor behaves in some ways like one doubly sized monitor.

I believe some of the problems you describe also occur with a single monitor. You can run the script from the editor in Trace mode from any point in the script without changing focus. However Trace mode ignores breakpoints so you probably would not be happy with that solution.

Macro Scheduler already has some capability to ignore itself. Perhaps this capability can be extended to breakpoint handling in an enhancement request.

In the meantime the best debugging method is to simply write to a logfile. You should be able to view it on the other monitor or even another computer. Search the forums for a "tail" script that always displays the most recent additions to the logfile. Of course you still don't have breakpoints.

Would it be acceptable if Macro Scheduler drew focus away from the application at breakpoints and then automatically put focus back on the application when you resume the script?



Gale

[SteenJakobsen]

Hi Gale,

Thanks a lot for your reply.

The case is really simple and has nothing to do with 2 or 3 monitors.
Having 2 or 3 monitors just makes it simpler to handle many applications
as they can be maximized on individual monitors.
Having 2 applications aligned next to each other on one monitor gives the same scenario.

Basically what I’m asking is :
Using a shortcut key - can I step the script 1 line at a time and watch the script progressing and watch the variables in the watch list without MacroScheduler Editor pulling the focus away.

I can currently stop the scrip using “Shift+Escâ€

[Marcus Tettmar]

Hi,

Have you tried this:

1. Uncheck the option Debug/Refocus Windows. This will prevent the editor taking focus away.
2. Use Debug/Trace.

Now you will see the script progress one line at a time but focus will NOT be stolen.

Unfortunately this is not possible in conjunction with Step. Why? Because for Macro Scheduler to recognise that you have pressed the step key it must have the focus! We can't give the editor keyboard focus to accept a debug step request without taking focus away from the target application. Hence we offer the Debug/Refocus Windows option which remembers what had the focus before the step line and switches back to it when the user steps.

Another conundrum of debugging is that the very nature of debugging introduces a delay. With scripts that fail because they are running too fast and/or the developer has not made the script wait for events to complete/windows to be ready, the script will often work fine in debug mode, because of the inherent delay introduced.

So really the only way to analyse real time progress is to use logging. Of course you can only then view the log file after the script has run.

[SteenJakobsen]

Thanks Marcus,

I'll try to combine some subrutines and event statements and waitkeydown
I thinik I can create a nice concept.

You should realy se our implementation of the SDK in a couple of weeks

[Marcus Tettmar]

Steen,

Take a look at the latest v12 beta build. Trace can now be set to a zero second interval. If you do this with Refocus Windows off you should get pretty much what you want.

In actual fact to avoid possible lockups and to allow the user to still kill the session in case of tight loops etc, the interval is set to 0.2 seconds. Previously the lowest possible interval was 1 second and setting trace to zero did nothing.

[jpuziano]

Another conundrum of debugging is that the very nature of debugging introduces a delay. With scripts that fail because they are running too fast and/or the developer has not made the script wait for events to complete/windows to be ready, the script will often work fine in debug mode, because of the inherent delay introduced.

So really the only way to analyse real time progress is to use logging. Of course you can only then view the log file after the script has run.

Note that even just turning on logging introduces additional delay as before, after or before and after execution of each line of a macro, it must write something to the logfile and that takes time. Not much time... but something... and that extra delay itself could make timing sensitive macros behave differently with logging on verses off.

Take care

[SteenJakobsen]

Hi,


Thanks a lot