ON *BUTTON?

[vefatica]

None of the "ON *BUTTON" commands seem to work ... tried with/without QuickEdit.

 

[rconn]

ON *BUTTON doesn't have anything to do with QuickEdit.

It seems to be working fine here -- how are you trying to trigger it? (You do know that it's not an asynchronous trigger? TCC has to be waiting for keyboard input.)

 

[vefatica]

ON *BUTTON doesn't have anything to do with QuickEdit.

It seems to be working fine here -- how are you trying to trigger it? (You do know that it's not an asynchronous trigger? TCC has to be waiting for keyboard input.)

I see ... like this

on lbutton beep
inkey %%foo

I noticed that it satisfies the INKEY but doesn't set the variable ... WAD?

 

[rconn]

I see ... like this

on lbutton beep
inkey %%foo

I noticed that it satisfies the INKEY but doesn't set the variable ... WAD?

WAD. If you want to set the variable, use INKEY /M and don't use ON LBUTTON.

 

[vefatica]

WAD. If you want to set the variable, use INKEY /M and don't use ON LBUTTON.

I was thinking it shouldn't satisfy the INKEY if INKEY isn't accepting mouse clicks. In what other circumstances would ON *BUTTON work?

 

[rconn]

I was thinking it shouldn't satisfy the INKEY if INKEY isn't accepting mouse clicks. In what other circumstances would ON *BUTTON work?

It's not "satisfying the INKEY"; it's interrupting INKEY and executing something else instead.

The other circumstances where ON *BUTTON would work would be any other time when TCC is expecting keyboard input. INPUT, PAUSE, LIST, SELECT, any internal command that takes interactive input (i.e., Y/N prompts), etc.

 

[Steve Fabian]

Rex:
This thread seems appropriate to ask:

1/ are ALL "ON" handlers of a batch file restored when a CALL'd batch file returns, or only - as documented in the paragrpah titled "Scope" of the "ON" command help topic - only the BREAK and ERROR handlers?

2/ How is ON scope affected by "calling a label", i.e., a part of the same batch file?

 

[Steve Fabian]

One additional question:
3/ How is ON scope affected when doing a GOSUB with an explicit filename? This has two subquestions - when the explicit file is actually the same as the one which executes the GOSUB, and the more common case of it being a different file...

 

[rconn]

Rex:
This thread seems appropriate to ask:

1/ are ALL "ON" handlers of a batch file restored when a CALL'd batch file returns, or only - as documented in the paragrpah titled "Scope" of the "ON" command help topic - only the BREAK and ERROR handlers?

2/ How is ON scope affected by "calling a label", i.e., a part of the same batch file?

1) The ON handlers only affect the current batch file level -- a CALL'd batch file is a nested file, so the ON handlers aren't referenced, and there's nothing to restore.

2) It's not affected at all; calling a label is done within the same batch file. But the question is probably moot, since that syntax is for batch files written for CMD.EXE, which doesn't support ON handlers anyway.

 

[rconn]

One additional question:
3/ How is ON scope affected when doing a GOSUB with an explicit filename? This has two subquestions - when the explicit file is actually the same as the one which executes the GOSUB, and the more common case of it being a different file...

"GOSUB filename" runs a nested batch file, so the ON handlers don't exist.

 

[Steve Fabian]

1) The ON handlers only affect the current batch file level -- a CALL'd batch file is a nested file, so the ON handlers aren't referenced, and there's nothing to restore.

The last sentence of HELP -> ON, subsection Scope:

"When control returns to the calling batch file, its break and error handlers that had been in effect at the CALL are reactivated."

I think this statement in the documentation is a leftover from the days when ON BREAK and ON ERROR were the only forms of ON, and should be amended to:

"When control returns to the calling batch file, all of its ONhandlers that had been in effect at the CALL are reactivated."

where underscore indicates modified text. This would be consonant with interpreting your above quoted statement to mean that the CALL'd batch file does not affect the caller's ON handlers.

2) It's not affected at all; calling a label is done within the same batch file. But the question is probably moot, since that syntax is for batch files written for CMD.EXE, which doesn't support ON handlers anyway.

While I agree with the original purpose of in-file CALL, CALL offers more flexibility than GOSUB for passing parameters, and for modifying passed parameters, so I would not be surprised if TCC-only users would take advantage of this feature. Regardless, your answer to my question was as expected - if control moves out of the file, ON does not propagate, but inside it does.

 

[rconn]

CALL offers more flexibility than GOSUB for passing parameters, and for modifying passed parameters

I have no idea what you mean by that ... I would say the exact opposite.