How to control what aggregated persistent data survives a copy/paste?

Ciao Emanuele!

Thanks for sharing your thoughts around this problem.

I'll try some more with getting the responders to work. I do get notification the very first time kCopyCmdBoss is executed. So it works once per session in ID which gives me some hope.

If I find a way to get notification to work I'll let you know and otherwise I'll try making an umbrella command like you suggested.

If anyone has any more insight to share, I'd appreciate it.

In Regards,
Magnus

Ciao Magnus!
You are facing a very special problem, which I already faced some months ago. I tried different approaches to solve this problem, but it seemed at the end that the SDK was leaking some notitications for the commands used in the copy/paste process, so there were no observers nor responders to properly attach for this purpose.

I experienced other problems then. For stories, the way ID internally handles the copy on the scrap db is actually a creation of a new kTextStoryBoss in which the internal content and attributes only are copied, but not the third-parties add-in'ed persistent interfaces.

As a final result, the only way for me to handle these cases properly was to implement my own kMyCopyCmdBoss and kMyPasteCmdBoss; in their Do methods I was wrapping the internal ID kCopyCmdBoss and kPasteCmdBoss with my own stuff, a sort of pre- and post-process of the ID commands I was calling. In such a way I had the possibility to control the copy/paste and do my own special instructions (especially on my own kTextStoryBoss' aggregated interfaces, where I needed to preserve some data). I must admit it's been difficult, especially for handling the other cases of copy/paste, like a selection of text for example. I am not mentioning the command you specifiy, since this command is triggered internally by ID in the context of a wider kCopyCmdBoss.

Another solution could start from responding to a special service provider called kNewStoryPhase2SignalRespServiceImpl, which is triggered each time a new story is being created. With this one, you could note how ID is creating a very new story on the scrap db when performing the copy and another one when performing the paste on a document. Maybe in your responder to this signal you can do something.

Finally, about the observer problems you mention. Actually, I had the same problems, and for certain ID commands (like the kDuplicateCmdBoss) I was forced to attach a command observer at the moment of the very startup of this command, i.e. thru a command interceptor. Then my observer was attaching to the ICommandMgr (and so, being notified for ANY command) and in the Update was checking on the "changedBy" to know if the command notified by the command manager was the one of interest. I was also looking for "theChange" to understand the moment of the notification (kBeforeDoMessageBoss, kBeforeUndoMessageBoss, and so on..). And as final bad thing, I was detaching this observer at the end of a successfull Update call, in order to stop observing immediatly after I was out of scope.

I don't know if this could help, I wanted just to share with you what I discovered, hopefully helping you a bit and not confusing you instead.

Ciao,
Emanuele