The moniker chunk will still hang around in this case. I honestly don't
know what you can do in this case. I was thinking of taking the old
visMoniker's chunk handle and using LMemFree, but once you have more than one
moniker you suddenly have to deal with the VisMonikerListEntry table (the
structure that manages multiple monikers). See Section 2.3 of the Objects
book for details on the structure of visMoniker lists. You can use this
structure to enumerate the list of monikers and free the one you don't need
anymore. Knowing which moniker to free might require examining the objects
from within Swat.
> One other question: Has anyone else tried the new compiler.mk file? It
> causes the compiler to give a warning practically (if not) every time I
use
> parentheses in my message parameters. For example, for this line of code
it
> says I should use parentheses to avoid being ambiguous:
>
> @call Object::MSG_GEN_ADD_CHILD(newitem, (CCF_MARK_DIRTY | CCO_LAST));
Check the .ec (or .nc) file and search for "newitem". See what the C code
looks like. This line doesn't look like it needs parentheses, but maybe the
.ec code will be more obvious as to where the problem is. Also, what are
"Object" and "newitem"? Are they expresssions that could use parentheses?
Nathan