pfuetz@zgdvda.UUCP (Matthias Pfuetzner) (05/09/90)
Hallo!
We're writing a UIMS consiting of a graphical shell (comparable to
GEM, but with dynamical aspects in creating of menus and all forms of
input-sets [menus, object-lists, strings, position-area, etc.], but
for those who know, it's based on our inhouse product THESEUS and is
called SIEMCAD) written in C and a dialogmanager (not only manager,
but also adviser, controller, helper) written in Prolog. Because this
product is written for Apollo WS (DN3000), we choose Quintus Prolog
Version 2.3. So, the main software control aspects and flow is as
follows:
C-part initializes graphical shell and starts the prolog part, saved
as a savestate, via QP_ipc_create_servant(). This savestate contains a
general predicate in/1 which accepts a string, parses this string and
determines what to do. This string is generated by the C-part of the
UIMS according to the actions done by the user:
The user selects action "line" in a menu and clicks two times in the
workarea of the window. Out of this the c-part generate a string "line
67 (231,21) (489,309)" which it sends to the prolog part via
QP_ipc_prepare(). Other possibilities are "arc", "marker", etc. The
number 67 corresponds to an existing window.
The prolog part then checks whether this is a valid action, whether
the user has done similar things for quit a time (eg. building
rectangles out of lines, etc.) and has to choose an action (providing
help, creating new macros, refusing action, etc.) which leads to a
call of a C-function defined in the C-part of the application.
Here our problem lies! Quintus Prolog only allows calls from C to
Prolog or vice versa. It isn't designed to call functions already
defined in a C-part available BEFORE the startup of the savestate. The
Prolog savestate starts recomiling the c-part for its own and thus has
no knowledge of already opened windows and is unable to draw the line
in the right window. It starts up his own c-system and tries to paint
the line somewhere there and not in the old window. One could perhaps
solve this problem by making prolog start a new process which it talks
to that sends these demands for an action to the old c-part. But this
is not the way we want it, because of the big overhead to be
generated!
If anybody out there knows a method how to work around this problem,
let me know!!
Sincerly,
Matthias
--
@work: | Matthias Pfuetzner | @home:
ZGDV, Wilhelminenstrasse 7 | 6100 Darmstadt, FRG | Lichtenbergstrasse 73
+49 6151 1000-22 or -77 \ <- Tel.nr. -> / +49 6151 75717
pfuetzner@agd.fhg.de pfuetzner@zgdvda.UUCP XBR1YD3U@DDATHD21.BITNET