Debugger issues: 1) Refocus doesn't refocus 2) F8 won't step

Rowland · Post by **Rowland** » Wed Jun 25, 2003 10:37 am

Issue 1) My code runs flawlessly when run, and I have the Refocus field checked, but when run in Debug mode, it simply doesn't refocus away from the Editor. However, this feature was working when I first installed MS (ver 7.2.036e).
Issue 2) When stepping through the code, the F8 command won't move past the first "Wait>.1" instruction.
Are these two issues related? Thanks in advance!
Here's the code:

//TurnWebMailDnLdOnOff.scp
// Recorded on Tuesday, June 24, 2003, at 12:42 AM
//Desc: toggles on/off the auto download of Internet mail
//Note: when turned off, mail is kept at the server and new mail can be viewed remotely
CapsOff
SetFocus>Inbox*
Press ALT
Wait>.1
Send>t
Wait>.1
Release ALT
Wait>.1
Send>o
Wait>.1
Press CTRL
Wait>.1
Press Tab * 6
Wait>1
Release CTRL
Wait>.1
Send>c
Wait>.5
Press Enter

Lumumba · Post by **Lumumba** » Wed Jun 25, 2003 10:52 am

Interesting, you use Wait>.1 instead of Wait>0.1.
Maybe this is OK for you, but is it the same for MSched?
Please check this out ...

BTW: try if it's possible to get rid of the Wait>commands

Code: Select all

SetFocus>Inbox*
Press ALT
Send>t
Release ALT
Send>o
Press CTRL
Press Tab * 6
Release CTRL
Send>c
Press Enter

Rowland · Post by **Rowland** » Wed Jun 25, 2003 11:38 am

Thanks for the reply. Yes, I eliminated all the "Wait"s, and it still runs fine!

Now..., if I could only discover the reason why the debugger isn't Refocusing...

Captive · Post by **Captive** » Sun Aug 24, 2003 7:12 pm

I'm wondering if it's due to many windows having similar, or the same names, or if "Inbox*" is a child window, etc.

One way to check, is to look at the list of windows (visible or otherwise) while the Inbox window is open. (Tools -> View system windows).

You could, just to test, include the SetFocus command in there again, and see if the debugger can re-focus that window again. (Yes I know after the 'SetFocus' command, it will go back to the debugger window

)

I've seen someone mention this issue before, where the debugger wouldn't refocus back to the previous window. I can't remember what the answer was, but perhaps you can use the forum search feature.

PeterT · Post by **PeterT** » Tue Nov 04, 2003 10:58 pm

I am also currently experiencing a similar problem to the one which Rowland discovered back in June this year, where the F8 key would not move past the first Wait>.1 instruction during Debug Stepping (see Issue 2 in his original post). My affected coding is below - F8 will not move past the first Wait instruction:

//Copy onto ClipBoard
SRT>Copy
Press CTRL
Wait>0.1
Send Character/Text>c
Wait>0.1
Release CTRL
Wait>0.1
End>Copy

As you can see, both Rowland's coding and mine have a Press command immediately before the affected point in the coding (his is an ALT and mine is CTRL). Could it be that the debugger will only react to F8 to move forward one step, and will NOT react to ALT-F8 or CTRL-F8 which in effect is the real situation - caused by the Press commands in our scripts??

As a test, I commented out the 'Press CTRL' command, and the debugger was then quite happy and stepped through the coding OK.

BTW: I am using the latest version of MacroScheduler (7.2.040e).

/Peter

support · Post by **support** » Thu Nov 06, 2003 4:40 pm

Hi,

Yes, the Press ALT (or CTRL or whatever) is of course causing subsequent F8 to be sent as ALT-F8 which is not the shortcut key for the debugger. Unfortunately we need the Press command to stay active so that the script does what you want. The answer is to use the mouse button and click the step toolbar button or menu shortcut.

This is one reason why we resisted including a debugger for so many years - there is a conundrum that crops up when debugging scripts that focus other windows and press keystrokes. The act of debugging itself breaks the script! Either we make the keystrokes do different things during debugging and therefore the script doesn't do what it is meant and therefore appears to fail (defeats the object of a debugger) or we rigidly let it do what it says it will do - in this case hold down the ALT key.

Another problem with debugging scripts is that you slow it down and in many cases it is timing issues which are the very reason a script isn't working quite as you expect, but debugging slows it down and therefore it appears to work during debugging! We're in a no win situation I'm afraid. I'd simply press the Debug Step toolbar button in this instance as that is independent of any keyboard state.

PeterT · Post by **PeterT** » Thu Nov 06, 2003 5:57 pm

Hello Support,

Thanks for your reply to this point.

I was going to suggest that MSched could react to any or all of the modifierkeys+F8 to step forward in the debug, but after seeing how many combinations you would potentially have to cover, then maybe this is not so practical. Or maybe there is an easy way for MSched to strip away the modifier keys and just see the bare-bones F8 that was pressed?? In the meantime, thanks for your suggestion to use the toolbar-button.

Whilst we are on the subject of the debugger - could MSched ignore (ie step through) any comments, blank lines, labels, Goto's etc when using the step function?? This would be a VERY nice addition to what is an excellent feature of MSched.

I have one or two other suggestions for 'improvements' in this debug area, but I will start these in new threads after I have investigated the existing features further (I am a newbie to MSched but not to IT Systems Development).

In the meantime, thanks for an excellent software product together with a first-class support structure,
Peter

GErickson · Post by **GErickson** » Thu Nov 06, 2003 6:21 pm

I heartily agree with Peter's request:

Whilst we are on the subject of the debugger - could MSched ignore (ie step through) any comments, blank lines, labels, Goto's etc when using the step function?? This would be a VERY nice addition to what is an excellent feature of MSched.

(... except for GoTo's -- I'm not sure what the issue there is. The script needs to step to the line containing the GoTo as usual, then the next step should go to the GoTo's destination, but not stop at the label line, but at the next executable line -- maybe that's what he was referring to.)

To make this a truly useful debugger, I would really like to have the ability to, after single-stepping for a while, continue running, and while running, to interrupt and stop the script and continue on single-stepping.

GErickson · Post by **GErickson** » Thu Nov 06, 2003 6:59 pm

support wrote:Hi,

Yes, the Press ALT (or CTRL or whatever) is of course causing subsequent F8 to be sent as ALT-F8 which is not the shortcut key for the debugger. Unfortunately we need the Press command to stay active so that the script does what you want. The answer is to use the mouse button and click the step toolbar button or menu shortcut.

This is one reason why we resisted including a debugger for so many years - there is a conundrum that crops up when debugging scripts that focus other windows and press keystrokes. The act of debugging itself breaks the script! Either we make the keystrokes do different things during debugging and therefore the script doesn't do what it is meant and therefore appears to fail (defeats the object of a debugger) or we rigidly let it do what it says it will do - in this case hold down the ALT key.

The answer to this is conceptually (not necessarily implementationally!) straightforward. Before each line of the script is interpreted, the target window -- the one that last had focus -- must be restored. Therefore the Press Alt gets sent to the target window, not to the debugger (though I'm not sure an Alt keystroke is really sent at this time, it may just affect what's sent by the next Send command).

When the debugger gets control back, it should update a list of what modifier keys are currently active (i.e., any that can be and have been pressed and haven't been released), then deactivate them for the debugger window so it doesn't interpret keys incorrectly. When the next line is to be executed by stepping with F8, first the focus should be restored to the target window, then the state of any modifier keys should be restored, before the new command is executed.

This could also be simplified if modified keys could be sent as part of a Send command, without all the Press & Release commands. For example, if you could Send>Alt-f,s,Alt-f,x, a file save and application exit could be executed by a single line. It would also make scripts much more readable.

GErickson · Post by **GErickson** » Thu Nov 06, 2003 7:03 pm

Captive wrote:... You could, just to test, include the SetFocus command in there again, and see if the debugger can re-focus that window again. (Yes I know after the 'SetFocus' command, it will go back to the debugger window )

I've seen someone mention this issue before, where the debugger wouldn't refocus back to the previous window. I can't remember what the answer was, but perhaps you can use the forum search feature. ...

I've seen the debugger stop restoring focus to the target window after a MessageModal> command. Adding a SetFocus> back to the target window after the MessageModal> seemed to work around the problem.

Guest · Post by **Guest** » Thu Nov 06, 2003 7:47 pm

With reference to GErickson's replies, I also heartily agree with all that he has said.

(... except for GoTo's -- I'm not sure what the issue there is. The script needs to step to the line containing the GoTo as usual, then the next step should go to the GoTo's destination, but not stop at the label line, but at the next executable line -- maybe that's what he was referring to.)

He was right to question if GoTo's should be included in the step-over. I don't think that I explained that very clearly, but he is right - execution should stop at the GoTo, and then continue at the next executable line following the GoTo label.

To make this a truly useful debugger, I would really like to have the ability to, after single-stepping for a while, continue running, and while running, to interrupt and stop the script and continue on single-stepping.

Now that would be VERY useful, especially when integrated with the BreakPoint - perhaps with a counter to denote how many times the breakpoint should be passed before it takes effect. This allows for a script to be auto-interrupted on say the 10th pass through.

Support wrote:

This is one reason why we resisted including a debugger for so many years - there is a conundrum that crops up when debugging scripts that focus other windows and press keystrokes.

I am VERY pleased that the developers finally overcame their resistance and included the debugger. For the development of complex scripts it is an absolute essential, and if it could include the features that we have already discussed (together with other features that will certainly be suggested by others), then it will be a first-class addition to what is already an excellent tool.

Peter

Bob Hansen · Post by **Bob Hansen** » Fri Nov 07, 2003 1:44 am

I have had success with inserting Breakpoints, clicking on Run, then pressing F8 to continue single stepping from the breakpoint. But I cannot reactivate Run again after single stepping from here. Would be nice to be able to continue.

GoTo> commands should definitely not be skipped in single step mode.
Only comment lines should be skipped.

But one concern that I have is that we currently can use almost any characters to ID a comment line. I would not want to give that up and be forced to use a common comment symbol. This would cause problems with legacy scripts. Right now I can use different symbols to ID different types of comment lines.

Debugger issues: 1) Refocus doesn't refocus 2) F8 won't step

Debugger issues: 1) Refocus doesn't refocus 2) F8 won't step

Desired Debugger Features

Debugger and keystrokes

Restoring focus