Re: closing a macro completely upon connect

Scott Caissie wrote:
Can you clarify your own posts? A few things are bothering me still.

sure

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.

note the qualifications in the above sentence. "Its been several years"
and "my recollection is ...".

1. First sentence we know is wrong. Partially. The example I gave you by
invoking a macro as a kverb works. Same example that you posted afterwards
as well. It has the ability to leave connect mode on its own and runs the
macro. A bridge is created.

Executing a macro as a kverb works when CONNECT was executed from a
script or macro but not when the CONNECT command is executed
interactively from the command prompt.

2. Rest of your paragraph explains everything that I'm looking for.

A macro mapped to a key will not execute if you enter CONNECT mode
directly. As described in the newbugs.txt file
* Fixed a bug preventing the execution of macros assigned to keys or
mouse events when in terminal mode

This applies to the case where the CONNECT command was executed
interactively from the command line.

3. Please don't say nesting. Don't even need to include Frank da Cruz's bug
description on this one. Your own bug description says its not possible to
begin with, so nesting never comes into play.
because as far as I am aware the macro is never executed when bound to a key
and the key is pressed while in CONNECT mode

Nesting will occur when the CONNECT command during which the \Kmacro is
executed was itself executed from within a script or macro.

4. Here you say it can't be done. You are now using my very own example to
say that the Kverb method is the proper way, though previously mentioned as
a 'work around' and a 'hack'.

The hack is the requirement that you replace "CONNECT" with the macro

define myconnect {
echo Foo
connect
echo Bar
}

or use

define myconnect connect /synch

Ya I get the picture that a macro won't actively run while in connect mode.
An amazing loss of potential there.

As described, this is a limitation of a command processor implemented in
a single threaded process model full of global variables up the wazoo.

I HAVE been re-reading what you are writting. I don't think you are proof
reading it.
Which is why I was confused as hell, and wondering what is a bug or not. You
had me half convinced that this feature is a bug, or a hack. Which is why I
was concerned of it being 'fixed'.

I am sorry you are mis-interpreting what I am writing.

But I have little worry in that now.
It is unfortunate to learn of K95's limits. I had such high hopes there.
They were real hopes too. I'm not kidding you. You get the book on how to
use the software. Only problem is that nothing in the book works without
using a hack, as you say, and even that apparently doesn't work right, when
you are using the software in any real productive way. But I do understand
how old k95 is.

The problem is not its age but a lack of resources to develop it. Being
forced to maintain a common set of sources for everything from a 1980
Unix system to Windows 2003 places certain limitations on what can be
done. That plus a lack of resources to re-write the command parser to
make it thread safe is a serious issue. With a thread safe and
re-entrant command parser the Kermit Script language could have been
executed via exported COM objects and you could have had multiple
scripts running simultaneously in the same process.

I'm still going to keep trying to push out its potential here beyond the
normal use. If you guys could modify VIEWONLY perhaps? So that it is what it
does. It is the CONNECT command that disables modifying anything. Its pauses
the macro.It would give the users the illusion of the screen not changing.
That itself would be enough to create a seemless use of a greater potential
here.

example:
define test {
viewonly
; coding which isn't being paused
connect /synchronous ; would effectively override viewonly.
}

VIEWONLY is identical to the CONNECT command except that no data is sent
to the host and no data is read from the host. It is there primarily to
allow the contents of the terminal screen buffers to be viewed when the
connection has already been closed.

At this point there is no one working on Kermit 95 therefore there are
no changes that will be made.

Good luck.

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: SEPKILL /im SMC.EXE /f
    ... Probably this bug exists on majorly all the software's but security software's like antivirus and firewall have to bucket it which is not what its for SEP. ... Save the following as a batch file and execute it ... If done from a batch file the command is completed only when the process is stopped. ...
    (Bugtraq)
  • 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)
  • Re: closing a macro completely upon connect
    ... Macros only execute in "command mode". ... fixed the bug associated with SET KEY and terminal mode, ... invoking a macro as a kverb works. ...
    (comp.protocols.kermit.misc)