Reconstruction

Our static object is created but it’s not used in exactly the same way. Again, abStatic is the intermediary and is read from the FRM file. Prior to processing each frame, GD is executed to move data from abStatic to our data object. That means that we potentially get a whole new copy of our static with each frame. We get whatever was in the static when our frame was being compiled with some important exceptions. The data that is restored is the data that was saved with PD. Anything else will be empty strings and 0 values.

This is very important: During reconstruction, we should assume that our static will be completely empty at the beginning of each frame. The only way to populate it with data is to load it from the FRM file with GD.

During reconstruction, the static is static. Let us say that we have some FORMAT and RETRIEVE methods that modify the static. If we never call GD, those changed values will persist. This is extremely dangerous. We have no idea of the order in which frames will be reconstructed or how many times a single frame might be processed. This is contrary to the nature of the static which is to save information or state from an earlier frame to be used in a later frame. It is entirely possible that, during reconstruction, the later frame will be processed first. Very bad things can happen if important data is allowed to persist during reconstruction. Therefore, although it is not strictly true, the statement above should be viewed that way.

But it gets better. PD is not called at the end of processing for ‘this’ frame. It’s called at the beginning of processing for the next frame. If you think about it, it makes great sense. What PD is doing is preserving the state of your data prior to any changes you might make.