Macro: Terminal -> Command -> Terminal -> Command? - Protocols

This is a discussion on Macro: Terminal -> Command -> Terminal -> Command? - Protocols ; I'm trying to find any possible way to allow a Macro to revert back to the COMMAND window "after" CONNECTing. Step #1 Terminal --> Command Set Key \96 \Ktest Define test { ; various commands CONNECT } While in the ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Macro: Terminal -> Command -> Terminal -> Command?

  1. Macro: Terminal -> Command -> Terminal -> Command?

    I'm trying to find any possible way to allow a Macro to revert back to the
    COMMAND window "after" CONNECTing.

    Step #1 Terminal --> Command
    Set Key \96 \Ktest
    Define test {
    ; various commands
    CONNECT
    }
    While in the TERMINAL, the key will bring you to the COMMAND window where
    the macro is processed.

    Step #2 Command --> Terminal
    Define test {
    ; various commands
    CONNECT
    }
    One the script is done, the CONNECT command goes to the TERMINAL.

    Step #3 ?? Terminal --> Command
    Now heres my question. Can a macro issue a command through OUTPUT or TRIGGER
    that will cause you to return back to the COMMAND window? I know you can't
    OUTPUT \Kexit.
    I'm not sure if TRIGGER is buggy or not but it loses its trigger in a
    certain situations without actually "triggering" you back to the COMMAND
    window. I'm not having much luck in getting OUTPUT and TRIGGER to work
    together.

    Example:
    SET TERMINAL TRIGGER TEST
    OUTPUT TEST
    CONNECT
    * Trigger is used up, but didn't actually trigger anything.


    - Scott



  2. Re: Macro: Terminal -> Command -> Terminal -> Command?

    Scott Caissie wrote:

    > Example:
    > SET TERMINAL TRIGGER TEST
    > OUTPUT TEST
    > CONNECT
    > * Trigger is used up, but didn't actually trigger anything.


    Triggers work on INPUT not on OUTPUT. If the host echo's the
    data back, then the trigger can be triggered. If the host doesn't
    echo the data back, then there is nothing to trigger on.

    If your terminal is in local-echo mode, then the host is not
    sending any data and the local-echo would have been processed
    when the OUTPUT command was executed. In that case, the trigger
    would not go off because you were not in CONNECT mode when the
    INPUT was processed.

    Scripts cannot control operations that are performed while the
    "terminal" is displayed to the end-user. The CONNECT command
    specifically gives control to the end-user and pauses the execution
    of scripts. The only exceptions are idle actions, triggers, and
    host driven events (file transfers, APCs, ...).

    Kermit does not have a mode that permits the command processor
    and the terminal to operate simultaneously because the command
    processor is not thread safe. Adding thread safety to the command
    processor will require a complete re-write.

    Jeffrey Altman

  3. Re: Macro: Terminal -> Command -> Terminal -> Command?

    I see. I've been testing this out all day, and it works pretty much the way
    I was aiming for. I was never referred to using the INPUT command before,
    and to be honest, I don't understand it 100% yet. I'm basically mirroring my
    actions.
    I do have a question. Is there restrictions about using INPUT 0 ?
    This example works fine, but if I use INPUT 0 etc, it won't. I check to see
    if it works by using \Fscrnstr(y,x,n) on a large scale.

    SET INPUT TERMINAL ON
    set input echo off
    clear input-buffer
    define vega {
    ..LZ_PRO := \Fscrnstr(0,6,8)
    OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    for \%t 1 24 1 {
    echo \Fscrnstr(\%t,0,79)
    }
    }


    "Jeffrey Altman" wrote in message
    news:lWShh.32651$tb6.31529@news-wrt-01.rdc-nyc.rr.com...
    > Scott Caissie wrote:
    >
    >> Example:
    >> SET TERMINAL TRIGGER TEST
    >> OUTPUT TEST
    >> CONNECT
    >> * Trigger is used up, but didn't actually trigger anything.

    >
    > Triggers work on INPUT not on OUTPUT. If the host echo's the
    > data back, then the trigger can be triggered. If the host doesn't
    > echo the data back, then there is nothing to trigger on.
    >
    > If your terminal is in local-echo mode, then the host is not
    > sending any data and the local-echo would have been processed
    > when the OUTPUT command was executed. In that case, the trigger
    > would not go off because you were not in CONNECT mode when the
    > INPUT was processed.
    >
    > Scripts cannot control operations that are performed while the
    > "terminal" is displayed to the end-user. The CONNECT command
    > specifically gives control to the end-user and pauses the execution
    > of scripts. The only exceptions are idle actions, triggers, and
    > host driven events (file transfers, APCs, ...).
    >
    > Kermit does not have a mode that permits the command processor
    > and the terminal to operate simultaneously because the command
    > processor is not thread safe. Adding thread safety to the command
    > processor will require a complete re-write.
    >
    > Jeffrey Altman




  4. Re: Macro: Terminal -> Command -> Terminal -> Command?

    On 2006-12-20, Scott Caissie wrote:
    : I see. I've been testing this out all day, and it works pretty much the way
    : I was aiming for. I was never referred to using the INPUT command before,
    : and to be honest, I don't understand it 100% yet. I'm basically mirroring my
    : actions.
    :
    I try to explain it succinctly here:

    http://www.columbia.edu/kermit/ckscripts.html#tut

    : I do have a question. Is there restrictions about using INPUT 0 ?
    : This example works fine, but if I use INPUT 0 etc, it won't. I check to see
    : if it works by using \Fscrnstr(y,x,n) on a large scale.
    :
    As far as I know, INPUT 0 should work OK in K95 2.1.3. I tested it just now,
    briefly, and it behaved as expected: succeeds if the text has already arrived
    but has not yet been processed, fails if the text is not there. I don't see
    anything in my notes about problems with or fixes to this.

    Incidentally, INPUT has a bunch of related variables that you might find
    useful. You can see them by typing "show var ^in" (show all the builtin
    variables whose names start with "in"):

    \v(input) = The current INPUT buffer contents (circular)
    \v(inchar) = The character most recently read by INPUT
    \v(incount) = 0 How many chars were read by the most recent INPUT
    \v(inmatch) = The string that the INPUT command matched
    \v(instatus) = -1 Status of last INPUT command
    \v(intime) = -1 Elapsed time for the most recent INPUT to complete
    \v(inwait) = 0 Time limit specified for most recent INPUT

    \v(inmatch) is useful with MINPUT, when you are looking for any of a
    number of strings to show up, so you know which one you got. This result
    is typically used as a SWITCH control, to process the event. It's also
    useful when using INPUT with \fpattern() to search for a pattern rather
    than a literal string, to know what the string was that matched the
    pattern.

    \v(instatus) is:
    0 if INPUT succeeded
    1 if the INPUT command timed out
    2 if the user interrupted the INPUT command from the keyboard
    3 (internal error, shouldn't happen)
    4 i/o error or connection lost.
    5 Kermit server active (INPUT attempted with WIKSD).

    For more information about the INPUT command, type HELP SET INPUT at the
    K-95> prompt.

    - Frank

  5. Re: Macro: Terminal -> Command -> Terminal -> Command?

    Scott Caissie wrote:
    > I see. I've been testing this out all day, and it works pretty much the way
    > I was aiming for. I was never referred to using the INPUT command before,
    > and to be honest, I don't understand it 100% yet. I'm basically mirroring my
    > actions.
    > I do have a question. Is there restrictions about using INPUT 0 ?
    > This example works fine, but if I use INPUT 0 etc, it won't. I check to see
    > if it works by using \Fscrnstr(y,x,n) on a large scale.
    >
    > SET INPUT TERMINAL ON
    > set input echo off
    > clear input-buffer
    > define vega {
    > ..LZ_PRO := \Fscrnstr(0,6,8)
    > OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    > INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    > for \%t 1 24 1 {
    > echo \Fscrnstr(\%t,0,79)
    > }
    > }


    If you use "INPUT 0 " you are not reading any data from the
    connection. You must use a timeout greater than 0 in order to process data.

    Jeffrey Altman

  6. Re: Macro: Terminal -> Command -> Terminal -> Command?

    That is what my tests today showed.
    With this, I'll have macros that will be running in a loop for about 50-200
    times.
    For each, I need only one "INPUT 1" statement at the end to update the
    screen. Up until that point, using a multitude of INPUT 0s works fine. 1 of
    my projects will need to update the screen twice.
    I ran one today a few times in a loop of 119 times. Worked perfectly.

    Though I wish you could allow for fractions of a second. Or an instaneous
    forced update command.
    That would be my wish list for Version 3.0.

    But this so far has helped me a lot. Thanks.

    - Scott

    "Jeffrey Altman" wrote in message
    news:4589b00f$0$16922$4c368faf@roadrunner.com...
    > Scott Caissie wrote:
    >> I see. I've been testing this out all day, and it works pretty much the
    >> way
    >> I was aiming for. I was never referred to using the INPUT command
    >> before,
    >> and to be honest, I don't understand it 100% yet. I'm basically mirroring
    >> my
    >> actions.
    >> I do have a question. Is there restrictions about using INPUT 0 ?
    >> This example works fine, but if I use INPUT 0 etc, it won't. I check to
    >> see
    >> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>
    >> SET INPUT TERMINAL ON
    >> set input echo off
    >> clear input-buffer
    >> define vega {
    >> ..LZ_PRO := \Fscrnstr(0,6,8)
    >> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >> for \%t 1 24 1 {
    >> echo \Fscrnstr(\%t,0,79)
    >> }
    >> }

    >
    > If you use "INPUT 0 " you are not reading any data from the
    > connection. You must use a timeout greater than 0 in order to process
    > data.
    >
    > Jeffrey Altman




  7. Re: Macro: Terminal -> Command -> Terminal -> Command?

    The value is a "timeout" period not a time-you-must-wait-for period.
    You could put 1000 there and it wouldn't make a different provided that
    the data you are looking for actually arrives. The value is "how long
    should I wait if the pattern I was given does not find a match on the
    incoming data stream?"



    Scott Caissie wrote:
    > That is what my tests today showed.
    > With this, I'll have macros that will be running in a loop for about 50-200
    > times.
    > For each, I need only one "INPUT 1" statement at the end to update the
    > screen. Up until that point, using a multitude of INPUT 0s works fine. 1 of
    > my projects will need to update the screen twice.
    > I ran one today a few times in a loop of 119 times. Worked perfectly.
    >
    > Though I wish you could allow for fractions of a second. Or an instaneous
    > forced update command.
    > That would be my wish list for Version 3.0.
    >
    > But this so far has helped me a lot. Thanks.
    >
    > - Scott
    >
    > "Jeffrey Altman" wrote in message
    > news:4589b00f$0$16922$4c368faf@roadrunner.com...
    >> Scott Caissie wrote:
    >>> I see. I've been testing this out all day, and it works pretty much the
    >>> way
    >>> I was aiming for. I was never referred to using the INPUT command
    >>> before,
    >>> and to be honest, I don't understand it 100% yet. I'm basically mirroring
    >>> my
    >>> actions.
    >>> I do have a question. Is there restrictions about using INPUT 0 ?
    >>> This example works fine, but if I use INPUT 0 etc, it won't. I check to
    >>> see
    >>> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>>
    >>> SET INPUT TERMINAL ON
    >>> set input echo off
    >>> clear input-buffer
    >>> define vega {
    >>> ..LZ_PRO := \Fscrnstr(0,6,8)
    >>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>> for \%t 1 24 1 {
    >>> echo \Fscrnstr(\%t,0,79)
    >>> }
    >>> }

    >> If you use "INPUT 0 " you are not reading any data from the
    >> connection. You must use a timeout greater than 0 in order to process
    >> data.
    >>
    >> Jeffrey Altman

    >
    >


  8. Re: Macro: Terminal -> Command -> Terminal -> Command?

    Its a pity that it can't be made faster. 1 second is too long when I have a
    macro using this numerous times per account.

    Anyway, I discovered an oddity.
    Is there a problem with INPUT & Kverbs?

    On of my macros is trying to use F6 (opens a window for me) but it doesn't
    function if it is by itself.
    I have 3 scenarios listed below.

    Scenario #1 (my original simple setup)
    OUTPUT \Kdecf06
    INPUT 1 \Kdecf06
    The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres no
    actual pause using 1 rather than 0.

    Scenario #2
    OUTPUT \Klfarr\Kdecf06
    INPUT 1 \Klfarr\Kdecf06
    This also doesn't work....still no actual pause or updating.

    Scenario #3
    OUTPUT \8\Kdecf06
    INPUT 1 \8\Kdecf06
    This works. I was wondering if Kverbs had complications with this.


    I had another macro which uses OUTPUT/INPUT very intensely and occassionally
    it loses it's place, and I think this might be the reason why. The terminal
    doesn't seem to always update when it should. Its going to take me about an
    hour to verify if all my statements are being processed correctly, but
    before I do that, I want to know precisely what I'm looking for.




    "Jeffrey Altman" wrote in message
    news:458a9baa$0$5926$4c368faf@roadrunner.com...
    > The value is a "timeout" period not a time-you-must-wait-for period.
    > You could put 1000 there and it wouldn't make a different provided that
    > the data you are looking for actually arrives. The value is "how long
    > should I wait if the pattern I was given does not find a match on the
    > incoming data stream?"
    >
    >
    >
    > Scott Caissie wrote:
    >> That is what my tests today showed.
    >> With this, I'll have macros that will be running in a loop for about
    >> 50-200
    >> times.
    >> For each, I need only one "INPUT 1" statement at the end to update the
    >> screen. Up until that point, using a multitude of INPUT 0s works fine. 1
    >> of
    >> my projects will need to update the screen twice.
    >> I ran one today a few times in a loop of 119 times. Worked perfectly.
    >>
    >> Though I wish you could allow for fractions of a second. Or an instaneous
    >> forced update command.
    >> That would be my wish list for Version 3.0.
    >>
    >> But this so far has helped me a lot. Thanks.
    >>
    >> - Scott
    >>
    >> "Jeffrey Altman" wrote in message
    >> news:4589b00f$0$16922$4c368faf@roadrunner.com...
    >>> Scott Caissie wrote:
    >>>> I see. I've been testing this out all day, and it works pretty much the
    >>>> way
    >>>> I was aiming for. I was never referred to using the INPUT command
    >>>> before,
    >>>> and to be honest, I don't understand it 100% yet. I'm basically
    >>>> mirroring
    >>>> my
    >>>> actions.
    >>>> I do have a question. Is there restrictions about using INPUT 0 ?
    >>>> This example works fine, but if I use INPUT 0 etc, it won't. I check to
    >>>> see
    >>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>>>
    >>>> SET INPUT TERMINAL ON
    >>>> set input echo off
    >>>> clear input-buffer
    >>>> define vega {
    >>>> ..LZ_PRO := \Fscrnstr(0,6,8)
    >>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>> for \%t 1 24 1 {
    >>>> echo \Fscrnstr(\%t,0,79)
    >>>> }
    >>>> }
    >>> If you use "INPUT 0 " you are not reading any data from the
    >>> connection. You must use a timeout greater than 0 in order to process
    >>> data.
    >>>
    >>> Jeffrey Altman

    >>
    >>




  9. Re: Macro: Terminal -> Command -> Terminal -> Command?

    What are you expecting

    OUTPUT \Kdecf06
    INPUT \Kdecf06

    to do?

    Since keyboard escape sequences are not going to be echo'd back to the
    terminal for input processing, it is the equivalent of

    INPUT "some string that is never ever going to come"

    You use the INPUT command to wait for the sequence that the host sends
    in response to the sequence you sent with OUTPUT.



    Scott Caissie wrote:
    > Its a pity that it can't be made faster. 1 second is too long when I have a
    > macro using this numerous times per account.
    >
    > Anyway, I discovered an oddity.
    > Is there a problem with INPUT & Kverbs?
    >
    > On of my macros is trying to use F6 (opens a window for me) but it doesn't
    > function if it is by itself.
    > I have 3 scenarios listed below.
    >
    > Scenario #1 (my original simple setup)
    > OUTPUT \Kdecf06
    > INPUT 1 \Kdecf06
    > The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres no
    > actual pause using 1 rather than 0.
    >
    > Scenario #2
    > OUTPUT \Klfarr\Kdecf06
    > INPUT 1 \Klfarr\Kdecf06
    > This also doesn't work....still no actual pause or updating.
    >
    > Scenario #3
    > OUTPUT \8\Kdecf06
    > INPUT 1 \8\Kdecf06
    > This works. I was wondering if Kverbs had complications with this.
    >
    >
    > I had another macro which uses OUTPUT/INPUT very intensely and occassionally
    > it loses it's place, and I think this might be the reason why. The terminal
    > doesn't seem to always update when it should. Its going to take me about an
    > hour to verify if all my statements are being processed correctly, but
    > before I do that, I want to know precisely what I'm looking for.
    >
    >
    >
    >
    > "Jeffrey Altman" wrote in message
    > news:458a9baa$0$5926$4c368faf@roadrunner.com...
    >> The value is a "timeout" period not a time-you-must-wait-for period.
    >> You could put 1000 there and it wouldn't make a different provided that
    >> the data you are looking for actually arrives. The value is "how long
    >> should I wait if the pattern I was given does not find a match on the
    >> incoming data stream?"
    >>
    >>
    >>
    >> Scott Caissie wrote:
    >>> That is what my tests today showed.
    >>> With this, I'll have macros that will be running in a loop for about
    >>> 50-200
    >>> times.
    >>> For each, I need only one "INPUT 1" statement at the end to update the
    >>> screen. Up until that point, using a multitude of INPUT 0s works fine. 1
    >>> of
    >>> my projects will need to update the screen twice.
    >>> I ran one today a few times in a loop of 119 times. Worked perfectly.
    >>>
    >>> Though I wish you could allow for fractions of a second. Or an instaneous
    >>> forced update command.
    >>> That would be my wish list for Version 3.0.
    >>>
    >>> But this so far has helped me a lot. Thanks.
    >>>
    >>> - Scott
    >>>
    >>> "Jeffrey Altman" wrote in message
    >>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
    >>>> Scott Caissie wrote:
    >>>>> I see. I've been testing this out all day, and it works pretty much the
    >>>>> way
    >>>>> I was aiming for. I was never referred to using the INPUT command
    >>>>> before,
    >>>>> and to be honest, I don't understand it 100% yet. I'm basically
    >>>>> mirroring
    >>>>> my
    >>>>> actions.
    >>>>> I do have a question. Is there restrictions about using INPUT 0 ?
    >>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check to
    >>>>> see
    >>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>>>>
    >>>>> SET INPUT TERMINAL ON
    >>>>> set input echo off
    >>>>> clear input-buffer
    >>>>> define vega {
    >>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
    >>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>> for \%t 1 24 1 {
    >>>>> echo \Fscrnstr(\%t,0,79)
    >>>>> }
    >>>>> }
    >>>> If you use "INPUT 0 " you are not reading any data from the
    >>>> connection. You must use a timeout greater than 0 in order to process
    >>>> data.
    >>>>
    >>>> Jeffrey Altman
    >>>

    >
    >


  10. Re: Macro: Terminal -> Command -> Terminal -> Command?

    I expect these commands to send and process the F6 key to the Terminal. The
    Terminal (for me) recognizes this as the Function Key for opening up various
    windows.

    And the command does in fact work. It sends out the F6 command to be
    processed by the Terminal.... but not when its alone. Its works as expected
    when its proceeded by a non-\Kverb. So I just throw in non-harmful keys in
    front of some of my sequences to guarantee that it will run properly.

    That sounds very much like a bug.


    "Jeffrey Altman" wrote in message
    news:45b0c5ad$0$7740$4c368faf@roadrunner.com...
    > What are you expecting
    >
    > OUTPUT \Kdecf06
    > INPUT \Kdecf06
    >
    > to do?
    >
    > Since keyboard escape sequences are not going to be echo'd back to the
    > terminal for input processing, it is the equivalent of
    >
    > INPUT "some string that is never ever going to come"
    >
    > You use the INPUT command to wait for the sequence that the host sends
    > in response to the sequence you sent with OUTPUT.
    >
    >
    >
    > Scott Caissie wrote:
    >> Its a pity that it can't be made faster. 1 second is too long when I have
    >> a
    >> macro using this numerous times per account.
    >>
    >> Anyway, I discovered an oddity.
    >> Is there a problem with INPUT & Kverbs?
    >>
    >> On of my macros is trying to use F6 (opens a window for me) but it
    >> doesn't
    >> function if it is by itself.
    >> I have 3 scenarios listed below.
    >>
    >> Scenario #1 (my original simple setup)
    >> OUTPUT \Kdecf06
    >> INPUT 1 \Kdecf06
    >> The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres
    >> no
    >> actual pause using 1 rather than 0.
    >>
    >> Scenario #2
    >> OUTPUT \Klfarr\Kdecf06
    >> INPUT 1 \Klfarr\Kdecf06
    >> This also doesn't work....still no actual pause or updating.
    >>
    >> Scenario #3
    >> OUTPUT \8\Kdecf06
    >> INPUT 1 \8\Kdecf06
    >> This works. I was wondering if Kverbs had complications with this.
    >>
    >>
    >> I had another macro which uses OUTPUT/INPUT very intensely and
    >> occassionally
    >> it loses it's place, and I think this might be the reason why. The
    >> terminal
    >> doesn't seem to always update when it should. Its going to take me about
    >> an
    >> hour to verify if all my statements are being processed correctly, but
    >> before I do that, I want to know precisely what I'm looking for.
    >>
    >>
    >>
    >>
    >> "Jeffrey Altman" wrote in message
    >> news:458a9baa$0$5926$4c368faf@roadrunner.com...
    >>> The value is a "timeout" period not a time-you-must-wait-for period.
    >>> You could put 1000 there and it wouldn't make a different provided that
    >>> the data you are looking for actually arrives. The value is "how long
    >>> should I wait if the pattern I was given does not find a match on the
    >>> incoming data stream?"
    >>>
    >>>
    >>>
    >>> Scott Caissie wrote:
    >>>> That is what my tests today showed.
    >>>> With this, I'll have macros that will be running in a loop for about
    >>>> 50-200
    >>>> times.
    >>>> For each, I need only one "INPUT 1" statement at the end to update the
    >>>> screen. Up until that point, using a multitude of INPUT 0s works fine.
    >>>> 1
    >>>> of
    >>>> my projects will need to update the screen twice.
    >>>> I ran one today a few times in a loop of 119 times. Worked perfectly.
    >>>>
    >>>> Though I wish you could allow for fractions of a second. Or an
    >>>> instaneous
    >>>> forced update command.
    >>>> That would be my wish list for Version 3.0.
    >>>>
    >>>> But this so far has helped me a lot. Thanks.
    >>>>
    >>>> - Scott
    >>>>
    >>>> "Jeffrey Altman" wrote in message
    >>>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
    >>>>> Scott Caissie wrote:
    >>>>>> I see. I've been testing this out all day, and it works pretty much
    >>>>>> the
    >>>>>> way
    >>>>>> I was aiming for. I was never referred to using the INPUT command
    >>>>>> before,
    >>>>>> and to be honest, I don't understand it 100% yet. I'm basically
    >>>>>> mirroring
    >>>>>> my
    >>>>>> actions.
    >>>>>> I do have a question. Is there restrictions about using INPUT 0
    >>>>>> ?
    >>>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check
    >>>>>> to
    >>>>>> see
    >>>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>>>>>
    >>>>>> SET INPUT TERMINAL ON
    >>>>>> set input echo off
    >>>>>> clear input-buffer
    >>>>>> define vega {
    >>>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
    >>>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>>> for \%t 1 24 1 {
    >>>>>> echo \Fscrnstr(\%t,0,79)
    >>>>>> }
    >>>>>> }
    >>>>> If you use "INPUT 0 " you are not reading any data from the
    >>>>> connection. You must use a timeout greater than 0 in order to process
    >>>>> data.
    >>>>>
    >>>>> Jeffrey Altman
    >>>>

    >>
    >>




  11. Re: Macro: Terminal -> Command -> Terminal -> Command?

    Scott:

    The OUTPUT command is working perfectly. Your INPUT command makes no
    sense and so you do not see the result of the OUTPUT command. If you
    have any doubts use "log debug" and take a look at what Kermit does
    in response to your command.

    As for bugs, well, as you know, there are no new updates coming from
    Columbia University anytime soon. If you want to hire me to look into
    bug reports, I will do so as my time permits.

    Jeffrey Altman


    Scott Caissie wrote:
    > I expect these commands to send and process the F6 key to the Terminal. The
    > Terminal (for me) recognizes this as the Function Key for opening up various
    > windows.
    >
    > And the command does in fact work. It sends out the F6 command to be
    > processed by the Terminal.... but not when its alone. Its works as expected
    > when its proceeded by a non-\Kverb. So I just throw in non-harmful keys in
    > front of some of my sequences to guarantee that it will run properly.
    >
    > That sounds very much like a bug.
    >
    >
    > "Jeffrey Altman" wrote in message
    > news:45b0c5ad$0$7740$4c368faf@roadrunner.com...
    >> What are you expecting
    >>
    >> OUTPUT \Kdecf06
    >> INPUT \Kdecf06
    >>
    >> to do?
    >>
    >> Since keyboard escape sequences are not going to be echo'd back to the
    >> terminal for input processing, it is the equivalent of
    >>
    >> INPUT "some string that is never ever going to come"
    >>
    >> You use the INPUT command to wait for the sequence that the host sends
    >> in response to the sequence you sent with OUTPUT.
    >>
    >>
    >>
    >> Scott Caissie wrote:
    >>> Its a pity that it can't be made faster. 1 second is too long when I have
    >>> a
    >>> macro using this numerous times per account.
    >>>
    >>> Anyway, I discovered an oddity.
    >>> Is there a problem with INPUT & Kverbs?
    >>>
    >>> On of my macros is trying to use F6 (opens a window for me) but it
    >>> doesn't
    >>> function if it is by itself.
    >>> I have 3 scenarios listed below.
    >>>
    >>> Scenario #1 (my original simple setup)
    >>> OUTPUT \Kdecf06
    >>> INPUT 1 \Kdecf06
    >>> The terminal won't update. In fact it acts like INPUT 0 \Kdecf06. Theres
    >>> no
    >>> actual pause using 1 rather than 0.
    >>>
    >>> Scenario #2
    >>> OUTPUT \Klfarr\Kdecf06
    >>> INPUT 1 \Klfarr\Kdecf06
    >>> This also doesn't work....still no actual pause or updating.
    >>>
    >>> Scenario #3
    >>> OUTPUT \8\Kdecf06
    >>> INPUT 1 \8\Kdecf06
    >>> This works. I was wondering if Kverbs had complications with this.
    >>>
    >>>
    >>> I had another macro which uses OUTPUT/INPUT very intensely and
    >>> occassionally
    >>> it loses it's place, and I think this might be the reason why. The
    >>> terminal
    >>> doesn't seem to always update when it should. Its going to take me about
    >>> an
    >>> hour to verify if all my statements are being processed correctly, but
    >>> before I do that, I want to know precisely what I'm looking for.
    >>>
    >>>
    >>>
    >>>
    >>> "Jeffrey Altman" wrote in message
    >>> news:458a9baa$0$5926$4c368faf@roadrunner.com...
    >>>> The value is a "timeout" period not a time-you-must-wait-for period.
    >>>> You could put 1000 there and it wouldn't make a different provided that
    >>>> the data you are looking for actually arrives. The value is "how long
    >>>> should I wait if the pattern I was given does not find a match on the
    >>>> incoming data stream?"
    >>>>
    >>>>
    >>>>
    >>>> Scott Caissie wrote:
    >>>>> That is what my tests today showed.
    >>>>> With this, I'll have macros that will be running in a loop for about
    >>>>> 50-200
    >>>>> times.
    >>>>> For each, I need only one "INPUT 1" statement at the end to update the
    >>>>> screen. Up until that point, using a multitude of INPUT 0s works fine.
    >>>>> 1
    >>>>> of
    >>>>> my projects will need to update the screen twice.
    >>>>> I ran one today a few times in a loop of 119 times. Worked perfectly.
    >>>>>
    >>>>> Though I wish you could allow for fractions of a second. Or an
    >>>>> instaneous
    >>>>> forced update command.
    >>>>> That would be my wish list for Version 3.0.
    >>>>>
    >>>>> But this so far has helped me a lot. Thanks.
    >>>>>
    >>>>> - Scott
    >>>>>
    >>>>> "Jeffrey Altman" wrote in message
    >>>>> news:4589b00f$0$16922$4c368faf@roadrunner.com...
    >>>>>> Scott Caissie wrote:
    >>>>>>> I see. I've been testing this out all day, and it works pretty much
    >>>>>>> the
    >>>>>>> way
    >>>>>>> I was aiming for. I was never referred to using the INPUT command
    >>>>>>> before,
    >>>>>>> and to be honest, I don't understand it 100% yet. I'm basically
    >>>>>>> mirroring
    >>>>>>> my
    >>>>>>> actions.
    >>>>>>> I do have a question. Is there restrictions about using INPUT 0
    >>>>>>> ?
    >>>>>>> This example works fine, but if I use INPUT 0 etc, it won't. I check
    >>>>>>> to
    >>>>>>> see
    >>>>>>> if it works by using \Fscrnstr(y,x,n) on a large scale.
    >>>>>>>
    >>>>>>> SET INPUT TERMINAL ON
    >>>>>>> set input echo off
    >>>>>>> clear input-buffer
    >>>>>>> define vega {
    >>>>>>> ..LZ_PRO := \Fscrnstr(0,6,8)
    >>>>>>> OUTPUT \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>>>> INPUT 1 \5\5\5\5\5\5\5\5\57\49\13\49\52\13\m(LZ_PRO)\24
    >>>>>>> for \%t 1 24 1 {
    >>>>>>> echo \Fscrnstr(\%t,0,79)
    >>>>>>> }
    >>>>>>> }
    >>>>>> If you use "INPUT 0 " you are not reading any data from the
    >>>>>> connection. You must use a timeout greater than 0 in order to process
    >>>>>> data.
    >>>>>>
    >>>>>> Jeffrey Altman
    >>>

    >
    >


  12. Re: Macro: Terminal -> Command -> Terminal -> Command?

    On 2007-01-20, Jeffrey Altman wrote:
    : The OUTPUT command is working perfectly. Your INPUT command makes no
    : sense and so you do not see the result of the OUTPUT command. If you
    : have any doubts use "log debug" and take a look at what Kermit does
    : in response to your command.
    :
    : As for bugs, well, as you know, there are no new updates coming from
    : Columbia University anytime soon. If you want to hire me to look into
    : bug reports, I will do so as my time permits.
    :
    To clarify: the OUTPUT command in Kermit 95 was designed to work with Kverbs,
    but the INPUT command was not. Insofar as a particular Kverb generates a
    string (as opposed to performing an action such as switching between the
    command and terminal screens, or scrolling back the current screen), it should
    be possible to access the strings, but currently it is not. This is something
    that could be done in a new release.

    The new release is something that is being considered by upper management at
    Columbia, at great length, as noted here:

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

    and here:

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

    A preview of the proposed new release is here:

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

    - Frank

+ Reply to Thread