Skip to main content

[Migrated content. Thread originally posted on 14 October 2004]

I am having a strange problem with my very large order entry program, which is a suite of programs with lots of calls and 5 screens. The second screen is where all the action happens, and there are 5 main ways to close an order. Each is driven by a graphical button, which executes a routine, and sets 'exit-pushed' to true; closing the second screen. The 5 routines appear to be identical, except that 2 of the 5 routines appear to ignore the 'set exit-pushed to true' leaving the screen hanging out there (flapping in the breeze). FYI this is a standard graphical program generated by acu-bench. I have done dozens of these types of programs before with no such behavior. The difference seems to be that this is quite a bit larger. Any general ideas on why, within an exception proc, the runtime would ignore a 'set exit pushed to true' ? Any general ideas would be greatly appreciated. Thanks.

[Migrated content. Thread originally posted on 14 October 2004]

I am having a strange problem with my very large order entry program, which is a suite of programs with lots of calls and 5 screens. The second screen is where all the action happens, and there are 5 main ways to close an order. Each is driven by a graphical button, which executes a routine, and sets 'exit-pushed' to true; closing the second screen. The 5 routines appear to be identical, except that 2 of the 5 routines appear to ignore the 'set exit-pushed to true' leaving the screen hanging out there (flapping in the breeze). FYI this is a standard graphical program generated by acu-bench. I have done dozens of these types of programs before with no such behavior. The difference seems to be that this is quite a bit larger. Any general ideas on why, within an exception proc, the runtime would ignore a 'set exit pushed to true' ? Any general ideas would be greatly appreciated. Thanks.
OK,

I've had similar problems, but when I want a button to do something and then make the program quit, these steps always work.

Always use Ex-Cmd-Clicked instead of Ev-Cmd-Clicked.
Always have SELF-ACT as FALSE

Also, I assume you're aware that if you don't need the press of the button to do anything other than quit, then just have an EXCEPTION-VALUE of 27 against it, but in this case set SELF-ACT to TRUE.

I usually go through this twice a week with the other developers who I look after.

Shaun

[Migrated content. Thread originally posted on 14 October 2004]

I am having a strange problem with my very large order entry program, which is a suite of programs with lots of calls and 5 screens. The second screen is where all the action happens, and there are 5 main ways to close an order. Each is driven by a graphical button, which executes a routine, and sets 'exit-pushed' to true; closing the second screen. The 5 routines appear to be identical, except that 2 of the 5 routines appear to ignore the 'set exit-pushed to true' leaving the screen hanging out there (flapping in the breeze). FYI this is a standard graphical program generated by acu-bench. I have done dozens of these types of programs before with no such behavior. The difference seems to be that this is quite a bit larger. Any general ideas on why, within an exception proc, the runtime would ignore a 'set exit pushed to true' ? Any general ideas would be greatly appreciated. Thanks.
OK,

I've had similar problems, but when I want a button to do something and then make the program quit, these steps always work.

Always use Ex-Cmd-Clicked instead of Ev-Cmd-Clicked.
Always have SELF-ACT as FALSE

Also, I assume you're aware that if you don't need the press of the button to do anything other than quit, then just have an EXCEPTION-VALUE of 27 against it, but in this case set SELF-ACT to TRUE.

I usually go through this twice a week with the other developers who I look after.

Shaun

[Migrated content. Thread originally posted on 14 October 2004]

I am having a strange problem with my very large order entry program, which is a suite of programs with lots of calls and 5 screens. The second screen is where all the action happens, and there are 5 main ways to close an order. Each is driven by a graphical button, which executes a routine, and sets 'exit-pushed' to true; closing the second screen. The 5 routines appear to be identical, except that 2 of the 5 routines appear to ignore the 'set exit-pushed to true' leaving the screen hanging out there (flapping in the breeze). FYI this is a standard graphical program generated by acu-bench. I have done dozens of these types of programs before with no such behavior. The difference seems to be that this is quite a bit larger. Any general ideas on why, within an exception proc, the runtime would ignore a 'set exit pushed to true' ? Any general ideas would be greatly appreciated. Thanks.
Shaun:

Thanks for the advice. I have not seen this behavior before in VERY similar programs. I will try what you suggest.

Matt C

[Migrated content. Thread originally posted on 14 October 2004]

I am having a strange problem with my very large order entry program, which is a suite of programs with lots of calls and 5 screens. The second screen is where all the action happens, and there are 5 main ways to close an order. Each is driven by a graphical button, which executes a routine, and sets 'exit-pushed' to true; closing the second screen. The 5 routines appear to be identical, except that 2 of the 5 routines appear to ignore the 'set exit-pushed to true' leaving the screen hanging out there (flapping in the breeze). FYI this is a standard graphical program generated by acu-bench. I have done dozens of these types of programs before with no such behavior. The difference seems to be that this is quite a bit larger. Any general ideas on why, within an exception proc, the runtime would ignore a 'set exit pushed to true' ? Any general ideas would be greatly appreciated. Thanks.
Matt,

If you still have a problem(we generally don't, unless its a really complex program), then there is another long winded way out of it.

Hopefully you wont need it though.

Shaun
Terms & ConditionsAccessibility statement