I don't think the external program finds a session so much as assumes it
is there. i.e. Before your EHLLAPI program runs, looking for Session A,
you already have a Session A emulator session active. Otherwise, (I may
be forgetting details here) your Connect Presentation Space is not going
to work.
Back when I last worked with that stuff, we had everything automated
such that a series of C programs presented a simple UI which was backed
up by other C programs and DOS BAT files that did things such as start
the required emulator sessions and then start the EHLLAPI code. But I
was the EHLLAPI user not the provider. Anyway, that is generally the way
it was done. I *knew* that, for example, Session A would be there
because I started Session A prior to entering my EHLLAPI code.
Hope that helps,
-Marty
----------------------------------------------------------------------
date: Tue, 28 Aug 2007 08:19:14 -0800
from: James Lampert <jamesl@xxxxxxxxxxxxxxxxx>
subject: Re: EHLLAPI for dummies?
Urbanek, Marty wrote:
When you say you want to "implement EHLLAPI in an emulator" rather
than call it, you're saying that you have the source code for an
emulator and you want to add EHLLAPI functionality to it (presumably
so that users of your emulator can write EHLLAPI programs)?
Yes, that's the general idea. And our emulator can (theoretically)
produce additional sessions until it runs out of memory. But it has no
provision to be controlled by anything other than keyboard/mouse input
or its own script language.
One of the main things I don't get is how an external program issuing
EHLLAPI calls finds an open emulator session (or, presumably more
precisely, how EHLLAPI finds one on behalf of a calling program) in the
first place.
--
James H. H. Lampert
Touchtone Corporation
midrange.com
