Skip to main content

Hi all,   Is it possible in AccuTerm to call another project from a command button in a different project.

I have developed a Customer Maintenance Project with 5 screens and a Customer Enquiry Project with 7 screens.

But my customer has now asked to be able to Call the Maintenance Project while in the middle of an Enquiry when they have noticed a problem that need updating, i.e.  wrong phone number.    can this be done or do I need to redevelop my whole maintenance again inside the Enquiry.

I have tried several things but nothing works as I had hopped

Can ANY ONE help by pointing the way please   haha



------------------------------
Chris Baxter
MD
CB Soft
IPSWICH GB
------------------------------

Hi all,   Is it possible in AccuTerm to call another project from a command button in a different project.

I have developed a Customer Maintenance Project with 5 screens and a Customer Enquiry Project with 7 screens.

But my customer has now asked to be able to Call the Maintenance Project while in the middle of an Enquiry when they have noticed a problem that need updating, i.e.  wrong phone number.    can this be done or do I need to redevelop my whole maintenance again inside the Enquiry.

I have tried several things but nothing works as I had hopped

Can ANY ONE help by pointing the way please   haha



------------------------------
Chris Baxter
MD
CB Soft
IPSWICH GB
------------------------------
Hi Chris,

Is this a text application or an AccuTerm GUI?

Joe Goldthwaite

Hi all,   Is it possible in AccuTerm to call another project from a command button in a different project.

I have developed a Customer Maintenance Project with 5 screens and a Customer Enquiry Project with 7 screens.

But my customer has now asked to be able to Call the Maintenance Project while in the middle of an Enquiry when they have noticed a problem that need updating, i.e.  wrong phone number.    can this be done or do I need to redevelop my whole maintenance again inside the Enquiry.

I have tried several things but nothing works as I had hopped

Can ANY ONE help by pointing the way please   haha



------------------------------
Chris Baxter
MD
CB Soft
IPSWICH GB
------------------------------

Yes .... but ....

Assuming you are talking about Accuterm GUI (seems reasonable seeing you are talking about a command button), then you can open a new form from the event handler attached to the button. The catch is that the form should be constructed as a "subroutine".

Look at programs GUI.MAIN, GUI.SUB1, and GUI.SUB2 in the GUIAPPS file for one example of opening multiple separate forms (ultimately using the ATGUISHOW subroutine). Or you could look at program MDI.MAIN which does something like what what you want by opening other applications by clicking on a button.

The key thing is that you need to be able to capture events from any visible form, and then pass that event to the correct handler.

HTH,

Brian



------------------------------
Brian Speirs
Senior Analyst - Information Systems
Rush Flat Ltd
Wellington NZ
------------------------------
Hi Chris,

Is this a text application or an AccuTerm GUI?

Joe Goldthwaite
Hi. Sorry I missed that bit out.
They are all AccuTerm projects.

Kind regards
Chris Baxter
CB Soft.

Yes .... but ....

Assuming you are talking about Accuterm GUI (seems reasonable seeing you are talking about a command button), then you can open a new form from the event handler attached to the button. The catch is that the form should be constructed as a "subroutine".

Look at programs GUI.MAIN, GUI.SUB1, and GUI.SUB2 in the GUIAPPS file for one example of opening multiple separate forms (ultimately using the ATGUISHOW subroutine). Or you could look at program MDI.MAIN which does something like what what you want by opening other applications by clicking on a button.

The key thing is that you need to be able to capture events from any visible form, and then pass that event to the correct handler.

HTH,

Brian



------------------------------
Brian Speirs
Senior Analyst - Information Systems
Rush Flat Ltd
Wellington NZ
------------------------------
Hi Brian,

Thanks for that but GUIAPPS does not contain GUI.MAIN etc etc
Managed to find MDI.MAIN but that a screen TEMPLATE (I think)
GUIAPPS contains only TEMPLATES ??

I am now going to search for those mentioned routines

Kind regards
Chris
CB Soft
M: 07841562498

Hi Brian,

Thanks for that but GUIAPPS does not contain GUI.MAIN etc etc
Managed to find MDI.MAIN but that a screen TEMPLATE (I think)
GUIAPPS contains only TEMPLATES ??

I am now going to search for those mentioned routines

Kind regards
Chris
CB Soft
M: 07841562498

Hi Chris -

As Brian said, you can use the multi-app model using subroutines instead of mainline programs. The problem you are facing is that AccuTerm GUI allows multiple forms to be "active" simultaneously. That is fine if the event handlers for all visible forms is the program running on the Pick machine. But if you EXECUTE a new GUI program from an existing GUI program, the new program will receive all events, even from forms displayed by the parent program. The new (child) program will not recognize events from the old (parent) program forms and will ignore them. Operators will perceive this as being hung.

There is a chapter in the Help on "multiple application model". That is what Brian is referring to. In this model, a master program calls individual GUI applications as subroutines. If the subroutine receives an unrecognized event, it RETURNs it back to the master program which attempts to locate the correct subroutine to handle the event. For complex applications, this model works quite well. But it is a bit more complex to set up.

There are two other approaches that you might consider. These are simpler to implement, but provide less flexibility. But that might not be an issue.

First idea is to change your maintenance program to a "dialog subroutine". Dialogs are modal, so if you call the maintenance (dialog) subroutine, the calling program is "disabled" until the subroutine returns. This ensures that forms from the calling program cannot generate events, hence there is no confusion about what program handles the events. For simple forms, this works well. You can even call dialog subroutines from green-screen programs. In your case, with 5 screens in the maintenance program, I don't recommend this approach, as each of the forms would need to be "dialog" style and this might be tricky to get working since only one form is allowed to be active.

The next idea, which I think will work well in your situation, is to leave the two program substantially the same, except in the inquiry program, at the point where you want to launch the maintenance program, use EXECUTE, but before the EXECUTE, disable the inquiry program application object (ATGUIDISABLE), and re-enable it when the EXECUTEd program returns (ATGUIENABLE). By disabling the inquiry program application, all of its forms will be disabled and unable to generate events. You need to make one modification in the maintenance program code (and if you expand this, maybe make same mod in all GUI programs, as it should not be an issue execute that a bit more memory will be used in Windows). In the GUI Trailer code section:

*-->BEGIN GUI TRAILER<--*
CALL ATGUISHUTDOWN
STOP
*-->END GUI TRAILER<--*

comment out the CALL AGUISHUTDOWN:

*-->BEGIN GUI TRAILER<--*
*CALL ATGUISHUTDOWN
STOP
*-->END GUI TRAILER<--*

If the child program calls ATGUISHUTDOWN, this would unload all of the GUI objects including those that belong to the parent program.

Hope this helps.

Thanks, Pete



------------------------------
Peter Schellenbach
Rocket Internal - All Brands
------------------------------

Hi Chris -

As Brian said, you can use the multi-app model using subroutines instead of mainline programs. The problem you are facing is that AccuTerm GUI allows multiple forms to be "active" simultaneously. That is fine if the event handlers for all visible forms is the program running on the Pick machine. But if you EXECUTE a new GUI program from an existing GUI program, the new program will receive all events, even from forms displayed by the parent program. The new (child) program will not recognize events from the old (parent) program forms and will ignore them. Operators will perceive this as being hung.

There is a chapter in the Help on "multiple application model". That is what Brian is referring to. In this model, a master program calls individual GUI applications as subroutines. If the subroutine receives an unrecognized event, it RETURNs it back to the master program which attempts to locate the correct subroutine to handle the event. For complex applications, this model works quite well. But it is a bit more complex to set up.

There are two other approaches that you might consider. These are simpler to implement, but provide less flexibility. But that might not be an issue.

First idea is to change your maintenance program to a "dialog subroutine". Dialogs are modal, so if you call the maintenance (dialog) subroutine, the calling program is "disabled" until the subroutine returns. This ensures that forms from the calling program cannot generate events, hence there is no confusion about what program handles the events. For simple forms, this works well. You can even call dialog subroutines from green-screen programs. In your case, with 5 screens in the maintenance program, I don't recommend this approach, as each of the forms would need to be "dialog" style and this might be tricky to get working since only one form is allowed to be active.

The next idea, which I think will work well in your situation, is to leave the two program substantially the same, except in the inquiry program, at the point where you want to launch the maintenance program, use EXECUTE, but before the EXECUTE, disable the inquiry program application object (ATGUIDISABLE), and re-enable it when the EXECUTEd program returns (ATGUIENABLE). By disabling the inquiry program application, all of its forms will be disabled and unable to generate events. You need to make one modification in the maintenance program code (and if you expand this, maybe make same mod in all GUI programs, as it should not be an issue execute that a bit more memory will be used in Windows). In the GUI Trailer code section:

*-->BEGIN GUI TRAILER<--*
CALL ATGUISHUTDOWN
STOP
*-->END GUI TRAILER<--*

comment out the CALL AGUISHUTDOWN:

*-->BEGIN GUI TRAILER<--*
*CALL ATGUISHUTDOWN
STOP
*-->END GUI TRAILER<--*

If the child program calls ATGUISHUTDOWN, this would unload all of the GUI objects including those that belong to the parent program.

Hope this helps.

Thanks, Pete



------------------------------
Peter Schellenbach
Rocket Internal - All Brands
------------------------------
Hi Peter,

Thanks for your reply, I have tried to implement the last approach. It works well (as long as you don't use execute Capturing haha)

But when ending the Maintenance - it closes all screens down.

Here is the Close event Handler

*
*
*-->BEGIN CLOSE EVENT HANDLER<--*
GUI.GUIPAT.CSMNT.CLOSE: *
CHG = 0
CALL ATGUIGETPROP(GUIAPP,GUIFRM,"",GPCHANGED,0,0,CHG,GUIERRORS,GUISTATE)
IF CHG THEN
CALL ATGUIMSGBOX("You have made changes!, do you want to abandon all your changes ?","Warning",3,4,"", GUIRESP, GUIERRORS, GUISTATE)
IF GUIRESP <> 6 THEN
RETURN
END
END
RELEASE
CUSTNO = ""
CALL ATGUIRESET(GUIAPP,GUIFRM,GUIERRORS,GUISTATE)
CALL ATGUISETPROP(GUIAPP,GUIFRM,"COMBCUST",GPITEMS,0,0,"",GUIERRORS,GUISTATE)
* Activate Cust No firls
CALL ATGUIACTIVATE(GUIAPP,GUIFRM,"COMBCUST",GUIERRORS,GUISTATE)
*
* Default form close event handler
CALL ATGUIHIDE(GUIAPP,GUIFRM,'','',GUIERRORS,GUISTATE)
IF GUIERRORS<1> >= 2 THEN GOTO GUI.ERROR
CALL ATGUIGETPROP(GUIAPP,'','',GPSTATUS,0,0,NUM.FORMS,GUIERRORS,GUISTATE)
IF GUIERRORS<1> >= 2 THEN GOTO GUI.ERROR
IF NUM.FORMS = 0 THEN
CALL ATGUIDELETE(GUIAPP,'','',GUIERRORS,GUISTATE)
IF GUIERRORS<1> >= 3 THEN GOTO GUI.ERROR
END
RETURN
*-->END CLOSE EVENT HANDLER<--*
*
I feel I should change this to close differently if I know I have been executed !! e.i. set a switch on a control file etc

Kind regards
Chris
CB Soft
M: 07841562498