Fabrice Harari International WinDev Consultant

Home         About Fabrice         WinDev Files        Products        Fabrice's blog         Consulting        Contact Fabrice        Links

My status

Random errors: what can cause them

Closing the calling window:
Once again, it's a gray area and something that is easy to find in simple cases... But when you are working in a complex UI and your process involves several classes and subclasses, you can in fact quite easily end up sawing the branch you are sitting on:

 

{AmazonLinks}


Let's say that a process starts in a window, by a right click menu, by example. This process is in charge of opening another window, resizing this and that, loading data to populate the window and so on... And somewhere in this code, it also closes the calling window... And even if the closing instruction was the last line of code executed, you would still be in trouble.

At this point, you have destroyed the object that was calling your processing code, which means, if you think again in terms of compiler and stack, that you have removed from the stack the object to which you have a returning address pointing in your current code...

The amazing part is that your program is going to continue working fine after that, at least for some time... And then, when you are executing some perfectly legit code, you will have a GPF...

Of course, the first question that comes to mind is why do such a thing? Why don't you just set a flag, close the first window, and in the main window do everything else because of the flag? The answer? Requirements... When the visual effect of the first window closing and then another one opening is outlawed, you have to find a solution...

So how can you solve that problem? One solution is a simple action list managed in the main window... In your originating event (in this example the right click menu item), you just add a line in the action list. In the main window, you have a timer looking for new actions to execute. When you start to execute one action, you stop your timer, as usual, and then you start your processing. Now there is 0 processing code originating in a window that will be closed, everything originates from the main window.

If you prefer to use a PostMessage to the window to be closed, well don't...

The first reason why you shouldn't is that your code is still originating from the window you are closing, and even if this window is closed after the code you are running, you don't know exactly when the code of the new window will run (before or after the original one is closed) and therefore what will happen to your address stack...

The second reason is that if you are confronted to a situation that requires this kind of problem solving, there is a very good chance that you are not working alone, and that your classes and subclasses are at some point calling code that you didn't write. You don't know if in this code somewhere there isn't a Multitask that will let the receiving event of your PostMessage fire before your own code is finished... And if you want more information about the Multitask/event problem, read this.

Google
 
Web www.fabriceharari.com
Links:


Last modified Friday, March 17, 2006 12:10 PM central time