wpInitData,
store it in wpSaveState, restore it in wpRestoreState,
and clean up in wpUnInitData.
However, if your instance data
consists of pointers to variable data which is allocated somewhere in the
class's implementation (e.g. in wpInitData), great care must be
taken to maintain data integrity.
When objects are copied, SOM per default does a so-called "shallow copy"
of the object's instance data. That is, the binary instance data is simply
copied to the new object. (From what I've seen, this is done by the
SOMObject::somDefaultConstAssign
method, which apparently is not overridden by any WPS class).
This is very dangerous for pointers because you then have two objects pointing
to the same memory block. If one of the objects is then deleted and frees its
storage (e.g. in wpUnInitData), the other object's member pointer
points to storage which has been freed.
This problem is a common one with C++ programming, and there you have the concept of copy constructors to take it into account. Unfortunately, the WPS docs never even mention this problem, even though the WPS programmers have most obviously been aware of it, since WPS methods exist to solve this.
From my checking, there are two possible solutions to this problem:
wpObjectReady. When objects are copied in any way
(either through wpCopyObject or wpCreateFromTemplate
or wpCreateAnother),
the ulCode parameter has the OR_REFERENCE bit set.
Then allocate a second buffer, copy the buffer data from the source object there
and adjust your member pointer.
When an object is copied, from my testing, wpObjectReady gets called
from wpCopyObject right before that method returns. See the
"Drag-copy trace session" for details.
wpCopyObject, wpCreateFromTemplate,
and wpCreateAnother
and do these things there. Call the parent first and adjust the data before returning.
This will be a bit later, but still work.