Hi Gastón;

My STD Framework has an "oe_close_all" event on the "Controller Window" ancestor class (wn_controller_master) that closes all open widows except itself. Again, using the 100% reverse order that any sheet, child, pop-up or response window was opened. The only difference in that logic is that it will *not* close itself. Thus, if the "Controller Window" is an MDI Frame, the last window in your app to remain open would be the MDI Frame (in your example). After that, you could then open the Login window dialogue form the MDI frame again..

Food for thought.

Regards ... Chris

Hi Chris,

My window controller is just a copy of your and it works perfectly. I manage to close all opened windows except from the MDI, display log in window and log user back again. My problem is that after all this, PB starts coming back on the call stack trying to execute the remaining code in all the method from all the objects



In my example (previously attached picture) w_surg_frame is our MDI window.

Execution steps are as follow:



6 - w_surg_frame.ue_log_off()

5 - n_cst_appmanager.of_inactiveapp()

4 - w_idle_warning.timer()

3 - n_barcode.of_show_barcode_data_window()

2 - w_case_record_sup_and_biling.of_process_scanned_item()

1 - w_case_record_sup_and_biling..sle_barcode_modified()



In step 6 all windows are closed, MDI frame remains opened, login window is displayed (response window). After the user types username and password control is returned to the ue_log_off event and continues processing to the end of the method. After that, control passes to step 5 and it processes remaining code on its method, Then to step 4 and do the same. And then to step 3 on n_barcode, and here comes the problem. n_barcode is an instance variable of w_case_record_sup_and_biling, of_show_barcode_data_window was the one that opened the response window and remains waiting there for the response of that window. In a normal situation the user would close the window entering new info or cancelling and we should be able to analyze the result and continue with the process. But in this case there were no user interaction, the window was close programmatically and as the control is returned to this specific step we try to continue doing the same as if it were closed on a "normal" situation.

An here is where the problem is coming, as the object was previously destroyed on step 5 and as we are trying to access properties on that objects but the object no longer exists, the application crashes (null exception).



Summarizing, when processing the call stack in reverse order PB is trying to access objects that were already destroyed by the log-off process.

Assuming that this is the way PB works my question is, is there any "generic" solution in order to avoid this behavior?

I know that it can be controlled by adding code on the methods that opens response windows, but the thin is that my app has around 500 response windows. Modifying all calling methods and testing would be challenging and loooong.



Sorry for the long descriptions and thank you for your help.

Hi Gastón;

Yes, this sounds very strange indeed! However, it could be a side effect of the way your App is designed. I am still wondering if you need a Flag that states you are closing everything and not to process any logic in any of the open window's Close or Close Query events like my framework does. Also, I would still recommend a Restart() if you want to avoid your App wows and make sure that all resources are cleaned up for the new login. Also, the restart approach would prevent you from modifying all your response window code. Just a thought.

Regards ... Chris

Unfortunately the problem is not to close the that task is correctly done, what happens is that after having closed the window PB continues processing the code that opened a response window even when I programmatically destroyed it.

Use the same idea: test to see if the window exists and is valid BEFORE running that code.