|
|
|||||
|
|
|
Random errors: what can cause them
|
|
||
|
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. |
|||||
| Links: |
|
||||