wpCopyObject
and such) actually do, who calls them, and what all these WPS threads
are doing.
To find out more, I have done an extensive debugging session tracing the
method calls during a copy operation.
You can find the whole log in the logs\copydrag.log
file.
The operation which was logged was a Ctrl-Drag (copy) of the "check.c"
file within the same folder so that the "File clash" dialog (actually,
my replacement) comes up, the target object is renamed, and then copying
actually starts.
During this operation, I roughly got the following:
wpSetTaskRec
on the source object to
prepare the wpCopyObject
call, which will later run
on the Tasker thread (TID 12 during my debugging).
This increases the task rec's usage count to 1.
wpMenuItemSelected
(during drag'n'drop!!)
on the source object being copied on TID 12. The Tasker
thread then calls wpFindTaskRec
to find out what to do.
wpConfirmObjectTitle
to
have the object renamed, if a name clash occurs.
wpCopyObject
.
So wpCopyObject
here ran on task 12!
wpCopyObject
calls wpFindTaskRec
again (even twice...).
wpCopyObject
creates a new SOM instance of the same class
as the source object. However, wpclsNew
does NOT get called.
I have yet to find out how this is done. On the new object,
the following method calls were traced (maybe the caller is
still wpCopyObject
or some other in-between-code):
-- wpInitData calls -- wpSetDefaultView -- wpSetDefaultIconPos -- is this copied from the task rec? -- wpSetAttr -- wpSetRealName calls -- wpCnrRefreshDetails -- wpSetType -- wpSetFolder -- wpModifyStyle -- wpLockObject -- wpSetTitle calls -- wpQueryConfirmations -- wpSetTitleAndRenameFile calls -- wpQueryFilename -- wpSetRealName (again!!) calls -- wpCnrRefreshDetails -- wpSetupOnce calls -- wpSetup calls -- wpSetTaskRec(pNew, NULL); pNew is the same TASKREC which was set for the source object -- but how does wpSetup know about the source object? Anyways, we now have a usage of 2; -- wpQueryContainerFlagPtr -- wpLockObject (again!!) -- wpQueryDefaultIconPos, preparing -- wpCnrInsertObject, calling LOTS of methods for inserting the object -- wpUnlockObject (undoes the second call);
Then we get a number of save/restore method calls (still in wpCopyObject
):
-- wpSaveState(pSource); -- wpRestoreState(pNew); aha!! (lots of method calls) -- wpModifyStyle(pNew), which calls wpQueryAttr on pSource (how does it know?) -- wpSetIcon(pNew); -- wpSaveDeferred(pNew).
THEN we finally get the wpObjectReady(pNew)
before
wpCopyObject(pSource)
returns.
In short, the initialization methods are as follows:
-- wpCopyObject(pSource) calls -- wpInitData(pNew); -- lots of wpSet*(pNew) calls; -- wpSetupOnce(pNew); -- wpCnrInsertObject(pNew); -- wpRestoreState(pNew)); -- wpSetIcon(pNew); -- wpObjectReady(pNew).
wpCopyObject
returns, wpQueryError
is checked and
wpSetTaskRec(NULL, pOld)
is invoked on the source object
and then the newly instantiated object, both times with
pOld
being the same task rec as above.
A few seconds later, wpSaveImmediate
is running on TID 10,
which apparently is the lazy writer thread which has been
informed by the wpSaveDeferred
call above.