Very Computer

by **Rod Falan** » Thu, 26 Oct 1995 04:00:00

We want to write a main menu application which will call other
OpenROAD applications. Not necessarily a CallFrame, or OpenFrame, but
an invoking of the OpenROAD application so that we can have separate
applications. I've got some questions related with it:

1) How do we do that? Do we use the "Call Runimage" call?

2) We need to set either some global constants or global variables
upon invoking the other application. How is this done?

Rod

Rod Falanga | (voice) 505-841-2511 (FAX) 505-841-2543

P.O. Box 4700 |
Albuquerque, NM 87196-4700 | The opinions expressed are mine alone.

by **Bodo Bergma** » Fri, 27 Oct 1995 04:00:00

>We want to write a main menu application which will call other
>OpenROAD applications. Not necessarily a CallFrame, or OpenFrame, but
>an invoking of the OpenROAD application so that we can have separate
>applications. I've got some questions related with it:
>1) How do we do that? Do we use the "Call Runimage" call?

Not possible on MS-Windows, because only one instance of a large model
application can run at a time (The OpenROAD runtime system application
"w4glrun.exe" is a large model application). This is a MS-Windows
limitation, not an OpenROAD limitation !

Quote:>2) We need to set either some global constants or global variables
>upon invoking the other application. How is this done?

If it would be possible to run a second applications (on other
OperatingSystems like UNIX, NT, ...) there are 2 ways to do that:
1.
Write your settings to a globals initialization file and start the
second application with the -g flag. File has to look like:
variable_or_constant_name = value
2.
Use the -/appflags (or -/include) - Metaflag when starting the second
application image to pass parameters to the image. Read these
parameters within the application (CurSession.Appflags) and set your
globals accordingly.
3.
Store the values of the globals to database or file before calling the
second application image. Read these values within the application
image (from database or file) and set your globals accordingly.

Because it is not possible to start another OpenROAD application from
an OpenROAD application you can:

1.
Built your main menu application as Windows-Executable and run the
selected OpenROAD image from there, example in "C":
WinExec("w4glrun -dnode::database myimage", 1);

2.
Use the other applications as included applications of your menu
application.
Instead of "call runimage" you'll have to use "callframe", "openframe"
or "callproc" to call the starting frame/procedure of the application
you want to call. If you have naming conflicts (same name for starting
component in different applications) you can use
"applicationname!componentname" to reference the right one.
Globals of included applications can be set directly.

Regards,
Bodo.

/*{
** Bodo Bergmann
** Client/Server- Consulting & Training
** Frankfurt, Germany
*/

by **Rod Falan** » Sat, 28 Oct 1995 04:00:00

BB> 2.
BB> Use the other applications as included applications of your menu
BB> application.
BB> Instead of "call runimage" you'll have to use "callframe", "openframe"
BB> or "callproc" to call the starting frame/procedure of the application
BB> you want to call. If you have naming conflicts (same name for starting
BB> component in different applications) you can use
BB> "applicationname!componentname" to reference the right one.
BB> Globals of included applications can be set directly.

Bodo,

If I use Application_A to call Application_B, as I understand it I have to
include Application_B into Application_A. Does that make Application_A the
size of Application_A (without Application_B) and Application_B?

Rod
--
Rod Falanga | (voice) 505-841-2511 (FAX) 505-841-2543

P.O. Box 4700 |
Albuquerque, NM 87196-4700 | The opinions expressed are mine alone.

by **Rod Falan** » Tue, 31 Oct 1995 04:00:00

>>> We want to write a main menu application which will call other
>>> OpenROAD applications. Not necessarily a CallFrame, or OpenFrame, but
>>> an invoking of the OpenROAD application so that we can have separate
>>> applications. I've got some questions related with it:
>>> 1) How do we do that? Do we use the "Call Runimage" call?
>> Not possible on MS-Windows, because only one instance of a large model
>> application can run at a time (The OpenROAD runtime system application
>> "w4glrun.exe" is a large model application). This is a MS-Windows
>> limitation, not an OpenROAD limitation !

CPC> When I read the Ref Manual description of "Runimage", it seemed that
CPC> it was designed _specifically to avoid_ the Windows 3.1 limitation.
CPC> That is, it would suspend the current image (a p-code file), and start
CPC> another image (another p-code file) under the control of the same
CPC> w4glrun.exe interpreter. That would explain the peculiar limitation:

CPC> "While the called application is executing,
CPC> no frames in the calling application are
CPC> active."

CPC> Am I wrong about this?

I don't know if you are wrong about this or not, but I NEED to know, so I'd
like to hear what others have to say about this.

Rod
--
Rod Falanga | (voice) 505-841-2511 (FAX) 505-841-2543

P.O. Box 4700 |
Albuquerque, NM 87196-4700 | The opinions expressed are mine alone.

by **Charles P. Coh** » Tue, 31 Oct 1995 04:00:00

>>We want to write a main menu application which will call other
>>OpenROAD applications. Not necessarily a CallFrame, or OpenFrame, but
>>an invoking of the OpenROAD application so that we can have separate
>>applications. I've got some questions related with it:
>>1) How do we do that? Do we use the "Call Runimage" call?
>Not possible on MS-Windows, because only one instance of a large model
>application can run at a time (The OpenROAD runtime system application
>"w4glrun.exe" is a large model application). This is a MS-Windows
>limitation, not an OpenROAD limitation !

When I read the Ref Manual description of "Runimage", it seemed that
it was designed _specifically to avoid_ the Windows 3.1 limitation.
That is, it would suspend the current image (a p-code file), and start
another image (another p-code file) under the control of the same
w4glrun.exe interpreter. That would explain the peculiar limitation:

"While the called application is executing,
no frames in the calling application are
active."

Am I wrong about this?

by **Bodo Bergma** » Tue, 31 Oct 1995 04:00:00

>Bodo,
>If I use Application_A to call Application_B, as I understand it I have to
>include Application_B into Application_A. Does that make Application_A the
>size of Application_A (without Application_B) and Application_B?

The size of Application_A remains the same, whether you include
Application_B or not.
Including an application is something like using a shared library or
DLL. Application_B is not copied into Application_A, but Application_A
contains only a reference to Application_B.
But there can be a difference in the size of the image file, that
contains Application_A.
If you specified no image file name in the Included Applications Sheet
then Application_B is included from the database. If you makeimage
Application_A then the image file contains both Application_A and
Application_B (because there is no extra image file for
Application_B).
If you specified an image file name in the Included Applications Sheet
then Application_B is included from that file (in the II_W4GLAPPS_DIR
directory). If you makeimage Application_A then the image file
contains only Application_A. Application_B has its own image file.

/*{
** Bodo Bergmann
** Client/Server- Consulting & Training
** Frankfurt, Germany
*/

by **Bodo Bergma** » Tue, 31 Oct 1995 04:00:00

Quote:>>>1) How do we do that? Do we use the "Call Runimage" call?
>>Not possible on MS-Windows, because only one instance of a large model
>>application can run at a time (The OpenROAD runtime system application
>>"w4glrun.exe" is a large model application). This is a MS-Windows
>>limitation, not an OpenROAD limitation !
>When I read the Ref Manual description of "Runimage", it seemed that
>it was designed _specifically to avoid_ the Windows 3.1 limitation.
>That is, it would suspend the current image (a p-code file), and start
>another image (another p-code file) under the control of the same
>w4glrun.exe interpreter. That would explain the peculiar limitation:
> "While the called application is executing,
> no frames in the calling application are
> active."
>Am I wrong about this?

Unfortunately, (I believe) you are wrong about this.
"Call runimage" was not designed to avoid any Windows 3.1 limitation.
The statement exists since W4GL 1.0 (there was no MS-Windows 3.1 at
that time). It is designed to call another image without using any
operating system dependent statement to run another W4GL application
(Portability) using the same database ( without specifying the
database name again).
Every "Call runimage" uses its own runtime system (w4glrun -
interpreter).

/*{
** Bodo Bergmann
** Client/Server- Consulting & Training
** Frankfurt, Germany
*/

by **Charles P. Coh** » Wed, 01 Nov 1995 04:00:00

>>When I read the Ref Manual description of "Runimage", it seemed that
>>it was designed _specifically to avoid_ the Windows 3.1 limitation.
>>That is, it would suspend the current image (a p-code file), and start
>>another image (another p-code file) under the control of the same
>>w4glrun.exe interpreter. That would explain the peculiar limitation:
>> "While the called application is executing,
>> no frames in the calling application are
>> active."
>>Am I wrong about this?
>Unfortunately, (I believe) you are wrong about this.
>"Call runimage" was not designed to avoid any Windows 3.1 limitation.
>The statement exists since W4GL 1.0 (there was no MS-Windows 3.1 at
>that time). It is designed to call another image without using any
>operating system dependent statement to run another W4GL application
>(Portability) using the same database ( without specifying the
>database name again).
>Every "Call runimage" uses its own runtime system (w4glrun -
>interpreter).

Brilliant design!<sick grin> Start up another interpreter process,
rather than saving the state of the one already running. [Sorry, I
was hoping that Rod would come out of this happy!]

I also realize that "saving the state of the one already running" is
not so easy in a database environment, and I shouldn't be so *
the designers for what is really a Windows 3.1 problem.

Very Computer

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.

OpenROAD on Windows: Invoking an OR app from another OR app.