Re: closing a macro completely upon connect
- From: "Scott Caissie" <scottac@xxxxxxxxxxxxxxx>
- Date: Sat, 11 Mar 2006 09:37:36 GMT
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
.
- Follow-Ups:
- Re: closing a macro completely upon connect
- From: Jeffrey Altman
- Re: closing a macro completely upon connect
- References:
- closing a macro completely upon connect
- From: Scott Caissie
- Re: closing a macro completely upon connect
- From: Jeffrey Altman
- Re: closing a macro completely upon connect
- From: Frank da Cruz
- Re: closing a macro completely upon connect
- From: Scott Caissie
- Re: closing a macro completely upon connect
- From: Frank da Cruz
- Re: closing a macro completely upon connect
- From: Scott Caissie
- Re: closing a macro completely upon connect
- From: Jeffrey Altman
- Re: closing a macro completely upon connect
- From: Scott Caissie
- Re: closing a macro completely upon connect
- From: Jeffrey Altman
- closing a macro completely upon connect
- Prev by Date: Re: No response on terminal line connection
- Next by Date: Re: closing a macro completely upon connect
- Previous by thread: Re: closing a macro completely upon connect
- Next by thread: Re: closing a macro completely upon connect
- Index(es):
Relevant Pages
|