------------------------------
Mohamed Azarudeen
junior developer
Rocket Forum Shared Account
------------------------------

Hi Mohamed,

This really depends on how your applications are written. If you are using a character mode program, then almost certainly you can only run one program per session. That said, you can easily run multiple sessions within Accuterm, and then switch between the sessions as required - or lay out the AccuTerm session windows side-by-side within the main AccuTerm window so you can see both at once.

If you write an AccuTerm GUI program, then you can have multiple windows open at once (not something that I like or allow), but it is up to you to write the application to allow this ... and if each window has to know what has happened in the other window, then you need to arrange the post of events between windows.

Cheers,

Brian

Hi Brian,

Thanks for your response.

Yes, I used the AccuTerm GUI program.

As you mentioned, I discovered this ATGUIPOSTEVENT subroutine in the Accuterm developer guide, but how can I use it between the applications? is there any way to call the program from the master application, if there is any library used for it?  I know nothing.

Again thank you for your response,

------------------------------
Mohamed Azarudeen
Rocket Forum Shared Account
------------------------------

Hi Brian,

Thanks for your response.

Yes, I used the AccuTerm GUI program.

As you mentioned, I discovered this ATGUIPOSTEVENT subroutine in the Accuterm developer guide, but how can I use it between the applications? is there any way to call the program from the master application, if there is any library used for it?  I know nothing.

Again thank you for your response,

------------------------------
Mohamed Azarudeen
Rocket Forum Shared Account
------------------------------

Hi Mohamed,

Log to the AccuTerm account on your system, and type:   DEMOMENU   (assuming you did a full install of the AccuTerm programs).

Run the 'Customer Maint' demo (under User Interface Design > GUI Demos). The login screen is just for show - it doesn't care what you enter or whether you enter anything at all. Select customer number 1119. You will see a couple of orders listed in the list box. Right-click on one of them and select 'Show details' (or double-click on an order).

Now, this demo ISN'T what you want - but it gets you started. It basically shows how you start from one window, and then open another.

This particular application has all the forms defined within the one GUI definition. That is OK for small applications, but the event responder program gets really big, really quickly. So it is better to break an application into "modules" (forms) with each module defined as its own application.  That means each module has its own GUI definition, and its own event responder program.

Read the GUI manual - particularly 'The GUI Designer > Code Models'.

Now, create a couple of modules using the "subroutine" code model (when you come to create the code). Make sure you define some "CUSTOM" events to load (or hide) each form.

Next, create a "main" program by copying the 'ATGUI.MAIN.SAMPLE' program in the GUIBP file. Update the reference in the ATGUIPOSTEVENT function to the first of your modules. That starts one of your modules. From that module, you could post a LOAD event to your second module to start that module. Thereafter, the code runs in whichever module is active, and if an event occurs that does not belong to that module, then the subroutine stack falls back to the main program whereupon the code is sent to the correct module.

I hope that gets you pointed in the right direction!

Cheers,

Brian

Hi Mohamed - 

Brian's advice is spot on. Take a look at GUI.MAIN, GUI.SUB1 and GUI.SUB2 as a simple example of using the multi-app model. ATGUIPOSTEVENT  with custom events like LOAD, SHOW, UNLOAD, etc. is simply a way to send a message from one part (subroutine) of a complex application to another part (subroutine). 

The one issue that is not addressed in the example is preserving the state of application parts. Since all local variables are lost when a subroutine RETURNs, we recommend using named common to preserve any variables (state) that will be needed when the subroutine is called in the future. 

Thanks, Pete