1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

ON *BUTTON?

Discussion in 'Support' started by vefatica, Oct 6, 2012.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    None of the "ON *BUTTON" commands seem to work ... tried with/without QuickEdit.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    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.)
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    I see ... like this
    Code:
    on lbutton beep
    inkey %%foo
    I noticed that it satisfies the INKEY but doesn't set the variable ... WAD?
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    WAD. If you want to set the variable, use INKEY /M and don't use ON LBUTTON.
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    I was thinking it shouldn't satisfy the INKEY if INKEY isn't accepting mouse clicks. In what other circumstances would ON *BUTTON work?
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    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.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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?
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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...
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    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.
     
  10. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    "GOSUB filename" runs a nested batch file, so the ON handlers don't exist.
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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.



    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.
     
  12. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,728
    Likes Received:
    80
    I have no idea what you mean by that ... I would say the exact opposite.
     

Share This Page