Re: closing a macro completely upon connect



Macros only execute in "command mode". Its been several years since I
fixed the bug associated with SET KEY and terminal mode, but my
recollection is that the macro would be configured to execute and
"terminal or connect mode" would not be exited.

Its this that I'm trying to understand.
You're saying that Macros can be executed in connect mode BUT can not run in
connect mode with the fix?
Then this fix is something that has no use to me.
I already created a work around to activate any macro via connect mode. I
want it to actively run while in connect mode.

This here was worded bad:
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).

All this time I was thinking the act of going to the command screen upon
invokation was the bug itself. It says 2 things. The secondary issue isn't a
concern.


Background program:
Actively saving the scrollback buffer and analying the last 30 lines which
is slightly more than a full screen worth of work, and do various events.
I have about 7-8 macros which upon activation causes a 'blink' effect. Jumps
to the command window, does the code involving the scrollback or something
else, and jumps back to the terminal. As far as my co-workers are concerned,
the macro 'reads the screen'. I wanted to remove the 'blink' effect. Not all
the users are comfortable with something that visually appears unstable.


I do have a technical question.
Lets say I have a macro that calls another macro (which this buggy one
does). If success, it does XX and Connects. If failure, it does nothing
aside from Connects.
Now if the ONLY means of getting to the Command window is through a Macro'd
hotkey, when it is used, does it cancel the immidate macro (which was paused
via the Connect command), or does it cancel all levels of the macro? (ie:
The parent macro which summoned it?). I think that is what is happening.
That afterall is what this thread is about. Not the macro invokation bug,
but the Macros being nested issue.

define test1 {
........
; checks keyboard cursor location. if success, then it does the rest
; this allows 1 key to be used to activate many macros. 1 at a time though
based on where you are in your work
; until this point, I never had macros calling macros.
if .... do test2
connect
return
}
define test2 {
; read scrollback
; output value
connect
return
}



"Jeffrey Altman" <jaltman2@xxxxxxxxxx> wrote in message
news:pVlQf.14280$4%1.10175@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Scott Caissie wrote:
But I still need to know what is being fixed.
Fix basically states that macros can be run from the Terminal without the
screen changing.

Where does http://www.columbia.edu/~jaltman/k95-fixes-since-213.txt
indicate that?

But normally, no complex macros can run (with or without set key) while
actively in the Terminal. They basically pause until you go back into the
Command window.

Macros only execute in "command mode". Its been several years since I
fixed the bug associated with SET KEY and terminal mode, but my
recollection is that the macro would be configured to execute and
"terminal or connect mode" would not be exited.

Can we have things running in the background now while in the Terminal?

You cannot have things executing in the background while in terminal
mode. Terminal mode is the "CONNECT" command. When the terminal window
is displayed the command processor is blocked in "CONNECT". Why is
this? Because the input and output devices are controlled by the user
when the CONNECT command is executed. The input and output devices
cannot be tampered with by a script.

The CONNECT command provides a trigger functionality that allows a
script to be executed when specific input patterns are recognized.
There is also an ability to automated output based upon idle timers.

What is it that you want to run in the background that would not be
competing with the user interaction with the remote host?

Thats what it sounds like. Though as far as I know, only 1 macro can run
at
a time. Invoking a macro in the Terminal while another macro (in a loop)
is
running in the background will cause the one in the background to stop
would
it not?

You are correct. There is one command processor and therefore one macro
at a time. This has not changed.

Jeffrey Altman


.



Relevant Pages

  • Re: MoveRight in table fails at 1%: bug? workaround?
    ... temporary files as your macro runs, so that all changes can be undone. ... about erros at Selection.MoveRight command? ... >> Does anyone know something like a known bug about MoveRight? ... Using the Selection object makes for more convoluted ...
    (microsoft.public.word.vba.general)
  • Re: closing a macro completely upon connect
    ... You mentioned 'temporarly' enters the command window. ... this is how all my macro definitions work, and are successful when used in ... :: Can you clarify your own posts? ... : aforementioned bug. ...
    (comp.protocols.kermit.misc)
  • Re: closing a macro completely upon connect
    ... fixed the bug associated with SET KEY and terminal mode, ... invoking a macro as a kverb works. ... interactively from the command prompt. ... A macro mapped to a key will not execute if you enter CONNECT mode ...
    (comp.protocols.kermit.misc)
  • Re: How to insert pdf attachment with word email merge?
    ... "Then execute to a new document the mail merge that you want to send out by ... document when you run the macro. ... Doug Robbins - Word MVP ...
    (microsoft.public.word.mailmerge.fields)
  • Re: alt x oddity
    ... The bug and the fix is so vague. ... commands) and use that macro about a hundred times or so, ... Error #2 looking at the COMMAND window with a flashing cursor. ...
    (comp.protocols.kermit.misc)