Change in processing of Accept/Quit trigger sequences between V8.4 D608 and V9.4

I know :-(

So I programmed my own SP_QUIT which will "ask" all depending instances (belonging to a TAB-widget) if or if not a quit will be accepted. If not, SP_QUIT will return $status=-1 and so the instance will stay alive.

A little bit tricky and sometimes there are still "loses" of instances :-)

Ingo

... wouldn't it be a good idea for the CPWR technical staff to provide some example code

"bringing all back the good times"?

I think they have good reasons for changing the behaviour,
on the other hand, they should have the best insider-knohow to provide the old functionality.

Success, Uli

This means that we should stop using trigger QUIT / ACCEPT, to control
if the users can or can not exit the component ?
The trigger QUIT / ACCEPT triggered the foremost trigger QUIT / ACCEPT child components.
If the first child component does not return an error it closes without waiting for other
 child components /or parent component are closed without error.

Hello,

There seems to be a problem when calling the Quit / Accept operation (e.g. “activate $instancename.quit()”) when using version 8.4.06 + D611 (or higher), version 9.2.03 resp. Service Pack MO01 (or higher), and version 9.3(.01 or higher). This issue has been recognized as (internal) bug report #28999 and a solution is (currently) planned for the (version 9.4.01) patch R109 (scheduled release date February 4, 2011) – a fix will most likely also be back ported to version 9.3 (probably to patch P219, planned for February 18, 2011).

If instead the Quit / Accept trigger is called (either by using e.g. 'macro "^QUIT"' / 'macro "^ACCEPT"' or with the structure editor function <GOLD>+Q / <GOLD>+A) then the deletion of the attached (child) instances is canceled in the described scenario (as expected).

Hope this helps.

Kind regards,
Daniel

*** Usual disclaimer ***