[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.
[archive] odd behavior
- Rocketeer
[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.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
- Rocketeer
[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.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
- Rocketeer
[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.Thanks for the advice. I have not seen this behavior before in VERY similar programs. I will try what you suggest.
Matt C
- Rocketeer
[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.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
Recent badge winners
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
