alt x oddity - Protocols

This is a discussion on alt x oddity - Protocols ; Alt X (\Kexit) has a slight oddity in it that I hope someone can explain to me. When I use Alt X while in CONNECT mode to reach COMMAND mode I get this situation: Pressing Alt X (or C) to ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: alt x oddity

  1. alt x oddity

    Alt X (\Kexit) has a slight oddity in it that I hope someone can explain to
    me.

    When I use Alt X while in CONNECT mode to reach COMMAND mode I get this
    situation:

    Pressing Alt X (or C) to return back to CONNECT mode. When activating a
    definition macro afterwards, it won't process. It just jumps to the COMMAND
    window's prompt. You can then re-try the macro and it'll work.

    There must be a very small detail I'm missing.
    All my macros, which are activated in CONNECT mode are formatted as:

    set key \## \kTest
    Define test {
    .....
    Connect
    Return
    }

    Now when I use this macro while in CONNECT mode, it rapidly jumps to COMMAND
    mode, where it does its thing, then immidately goes back into CONNECT mode.
    I do this repeatedly and everything is perfect.

    Never am I stuck at the prompt using my macros.
    Why then does using the commands, Alt X or C, manually not have the same
    effect? Why does it negate the next definition type macro used?



  2. Re: alt x oddity

    On 2006-05-04, Scott Caissie wrote:
    : Alt X (\Kexit) has a slight oddity in it that I hope someone can explain
    : to me.
    :
    : When I use Alt X while in CONNECT mode to reach COMMAND mode I get this
    : situation:
    :
    : Pressing Alt X (or C) to return back to CONNECT mode. When activating a
    : definition macro afterwards, it won't process. It just jumps to the COMMAND
    : window's prompt. You can then re-try the macro and it'll work.
    :
    : There must be a very small detail I'm missing.
    : All my macros, which are activated in CONNECT mode are formatted as:
    :
    : set key \## \kTest
    : Define test {
    : ....
    : Connect
    : Return
    : }
    :
    : Now when I use this macro while in CONNECT mode, it rapidly jumps to COMMAND
    : mode, where it does its thing, then immidately goes back into CONNECT mode.
    : I do this repeatedly and everything is perfect.
    :
    : Never am I stuck at the prompt using my macros.
    : Why then does using the commands, Alt X or C, manually not have the same
    : effect? Why does it negate the next definition type macro used?
    :
    See the recent thread on this same topic. This is one of the most annoying
    bugs in Kermit 95 2.1.3: macros assigned to keystrokes simply do not work as
    expected. Quoting from ftp://kermit.columbia.edu/kermit/k95/newbugs.txt :

    735. Macros on Keys broken

    In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    includes a macro invocation, then pressing the key while in the
    Terminal screen returns to the command screen (and in some cases might
    also fail to execute the macro). A workaround would be to:

    define myconnect connect /synchronous
    (make the connection with SET PORT, DIAL, or SET HOST)
    if success do myconnect

    This is fixed in the next release.

    And then to address the inevitable next question, "How do I get the fix?" or
    "When will the next release come out?", see:

    http://www.columbia.edu/kermit/support.html

    - Frank

  3. Re: alt x oddity

    is there a great amount of technical detail as to what the fix actually
    does? The bug and the fix is so vague.

    I did discover another problem with those macros. Its a very percular one
    involving IF and ELSE statements.
    If I have a macro with a number of IF statements (using bracketed off
    commands) and use that macro about a hundred times or so (very realistic),
    theres a chance of an error occuring.
    Error #1 pop up box saying it encountered a problem and needs to close.
    Error #2 looking at the COMMAND window with a flashing cursor. Effectively
    frozen. Can't break out of it. Must close the program.

    By chance I discovered that adding ELSE statements, even empty ones,
    drastically reduces this. So I do this all the time though it looks silly.

    example:
    SET KEY \## \KTEST

    DEFINE TEST {
    IF NOT DEF \%A {
    MISC 1
    MISC 2
    } ELSE {
    }
    CONNECT /SYNCHRONOUS (spelling?)
    RETURN
    }

    I'm only assuming that repeated use of the Macros causes a problem with the
    Brackets. The last bracket (and anything after CONNECT) is never reached as
    far as I know. The ELSE statements seems to help reassure the structure of
    the macro, but not completely.

    Thats my observation so far. Those empty else statements worked wonders but
    still not perfect.



    "Frank da Cruz" wrote in message
    news:slrne5k1te.ik6.fdc@sesame.cc.columbia.edu...
    > On 2006-05-04, Scott Caissie wrote:
    > : Alt X (\Kexit) has a slight oddity in it that I hope someone can explain
    > : to me.
    > :
    > : When I use Alt X while in CONNECT mode to reach COMMAND mode I get this
    > : situation:
    > :
    > : Pressing Alt X (or C) to return back to CONNECT mode. When activating a
    > : definition macro afterwards, it won't process. It just jumps to the
    > COMMAND
    > : window's prompt. You can then re-try the macro and it'll work.
    > :
    > : There must be a very small detail I'm missing.
    > : All my macros, which are activated in CONNECT mode are formatted as:
    > :
    > : set key \## \kTest
    > : Define test {
    > : ....
    > : Connect
    > : Return
    > : }
    > :
    > : Now when I use this macro while in CONNECT mode, it rapidly jumps to
    > COMMAND
    > : mode, where it does its thing, then immidately goes back into CONNECT
    > mode.
    > : I do this repeatedly and everything is perfect.
    > :
    > : Never am I stuck at the prompt using my macros.
    > : Why then does using the commands, Alt X or C, manually not have the same
    > : effect? Why does it negate the next definition type macro used?
    > :
    > See the recent thread on this same topic. This is one of the most
    > annoying
    > bugs in Kermit 95 2.1.3: macros assigned to keystrokes simply do not work
    > as
    > expected. Quoting from ftp://kermit.columbia.edu/kermit/k95/newbugs.txt :
    >
    > 735. Macros on Keys broken
    >
    > In versions 1.1.21 through 2.1.3, when a SET [TERMINAL] KEY definition
    > includes a macro invocation, then pressing the key while in the
    > Terminal screen returns to the command screen (and in some cases might
    > also fail to execute the macro). A workaround would be to:
    >
    > define myconnect connect /synchronous
    > (make the connection with SET PORT, DIAL, or SET HOST)
    > if success do myconnect
    >
    > This is fixed in the next release.
    >
    > And then to address the inevitable next question, "How do I get the fix?"
    > or
    > "When will the next release come out?", see:
    >
    > http://www.columbia.edu/kermit/support.html
    >
    > - Frank




  4. Re: alt x oddity

    On 2006-05-05, Scott Caissie wrote:
    : is there a great amount of technical detail as to what the fix actually
    : does? The bug and the fix is so vague.
    :
    Kermit 95 runs in multiple threads that have to be synchronized. The command
    screen and the terminal screen are just two examples. Executing commands
    while in the terminal screen's context is rather tricky business and that's
    where the bug is.

    : I did discover another problem with those macros. Its a very percular one
    : involving IF and ELSE statements.
    : If I have a macro with a number of IF statements (using bracketed off
    : commands) and use that macro about a hundred times or so (very realistic),
    : theres a chance of an error occuring.
    : Error #1 pop up box saying it encountered a problem and needs to close.
    : Error #2 looking at the COMMAND window with a flashing cursor. Effectively
    : frozen. Can't break out of it. Must close the program.
    :
    I suspect this is an artifact of the same bug. If you invoke the same macro
    from the command context the same number of times, I suspect it you won't
    see a problem. Again, see our support page:

    http://www.columbia.edu/kermit/support.html

    A version of K95 is available that fixes the bug, but it's not free due to
    the circumstances explained on the support page. I continue to work to make
    the needed arrangements to release a new version with this fix and many others
    and quite a few new features as well. But it will likely not be free either.

    - Frank

+ Reply to Thread