Skip to main content

[Migrated content. Thread originally posted on 06 January 2006]

We have a program with two Bench generated screens and code. One is an order "pad" and the other is an order "header". They idea is that users can add line items to an order and then visit the header to complete the order if its a sale. Also, desired is the ability to visit one screen or the other at will. One screen is set to be the first screen displayed and executed. Push buttons on either screen are being used with "Link To" paragraphs and termination values.

The program simply performs the selected Bench generated code path i.e.

Perfrom "Acu-Screen1-Routine" or "Acu-Screen2-Routine" with appropriate modify statements for visible and enabled properties.

This works but the caveat is the perform stack limit which is eventually reached by continously "buttoning" back and forth. Increasing the stack size is possible but there is always a limit that can be reached eventually which is in effect an "Achille's Heel".

Management did not like the look of tabs so this route was taken. Is there a known solution to this problem. The screen handling for both screens is 100% Bench generated code and we would rather not depart from that.

Regards

Vins Nash

[Migrated content. Thread originally posted on 06 January 2006]

We have a program with two Bench generated screens and code. One is an order "pad" and the other is an order "header". They idea is that users can add line items to an order and then visit the header to complete the order if its a sale. Also, desired is the ability to visit one screen or the other at will. One screen is set to be the first screen displayed and executed. Push buttons on either screen are being used with "Link To" paragraphs and termination values.

The program simply performs the selected Bench generated code path i.e.

Perfrom "Acu-Screen1-Routine" or "Acu-Screen2-Routine" with appropriate modify statements for visible and enabled properties.

This works but the caveat is the perform stack limit which is eventually reached by continously "buttoning" back and forth. Increasing the stack size is possible but there is always a limit that can be reached eventually which is in effect an "Achille's Heel".

Management did not like the look of tabs so this route was taken. Is there a known solution to this problem. The screen handling for both screens is 100% Bench generated code and we would rather not depart from that.

Regards

Vins Nash
Originally posted by vinsnash
This works but the caveat is the perform stack limit which is eventually reached by continously "buttoning" back and forth.


It sounds to me like the control of the second screen is issued from within the event procedure of the first screen. Given the technique you want to use, this is not a desireable method.

Change your application so that the button that is supposed to give focus to the second window will terminate the first accept and return a certain exception value (your choice, but avoid mixing with existing values), outside the accept, test for the exception value and launch / relaunch the second window in a separate thread, if it is already running, change focus to that thread, then go back into the accept of the first screen again without having destroyed it.

[Migrated content. Thread originally posted on 06 January 2006]

We have a program with two Bench generated screens and code. One is an order "pad" and the other is an order "header". They idea is that users can add line items to an order and then visit the header to complete the order if its a sale. Also, desired is the ability to visit one screen or the other at will. One screen is set to be the first screen displayed and executed. Push buttons on either screen are being used with "Link To" paragraphs and termination values.

The program simply performs the selected Bench generated code path i.e.

Perfrom "Acu-Screen1-Routine" or "Acu-Screen2-Routine" with appropriate modify statements for visible and enabled properties.

This works but the caveat is the perform stack limit which is eventually reached by continously "buttoning" back and forth. Increasing the stack size is possible but there is always a limit that can be reached eventually which is in effect an "Achille's Heel".

Management did not like the look of tabs so this route was taken. Is there a known solution to this problem. The screen handling for both screens is 100% Bench generated code and we would rather not depart from that.

Regards

Vins Nash
Thank you sir.

That works. The trick appears to be just to break the perform loop. I've set it up so that screen 'a' performs screen 'b' and screen 'b' simply terminates. Nothing is lost because all the values are still in working storage and display again when the screen 'b' routine is perform anew.
Terms & ConditionsAccessibility statement