I have ModelView that derives from GoView and a GraphNode that derives
from GoGeneralNode. I can cut and paste the GraphNode ok and I
can serialize/deserialize the ModelView without error. The
problem occurs when I paste multiple times. The time it takes to paste
the GraphNode into the view increases with each paste. I
have override of CopyObject in my GraphNode class but the delay occurs
before the call to CopyObject is invoked. How do figure out what
is happening between my call to GoView.EditPaste() and the subsequent
call to GraphNode.CopyObject?
This is Windows Forms, right?
You can’t meaningfully serialize a GoView, since GoView inherits from Control which inherits from MarshalByRefObject.
You should be serializing the GoDocument and its GoObjects, not the GoView. Those objects should not have any references to Controls or to other non-serializable objects, unless you are prepared to handle the null references after deserialization.
For your information, GoView.PasteFromClipboard takes deserialized data from the clipboard and (assuming it’s a GoDocument) is copied into the GoView’s document by calling GoDocument.CopyFromCollection.
I mis-spoke. I have ModelView (derived from GoView) that has
event handlers for “copy”/'paste" menu items. I have
ModelDocument (derived from GoDocument) that contains GraphNode
(derived from GoGeneralNode). I can serialize/deserialize the
GoDocument to/from XML without error. I can copy and paste
individual GraphNode without error. However… if I copy
GraphNode to clipboard and invoke “paste” multiple times, the time it
takes to add the GraphNode copy to the document increases with each
paste.
Code in the ModelView class is as follows:
&nbs p; StartTransaction();
this.Selection.Clear();
base.EditPaste();
FinishTransaction("Context Paste");
Running in debug mode, I find that the time between EditPaste() call
and subsequent call to CopyObject is increasing with each paste.
The serialization that the clipboard uses is binary object serialization, not XML.
For those people who happen to read this forum topic, you can test your document serialization using the code given in http://www.nwoods.com/forum/forum_posts.asp?TID=880.
You can narrow down the code that you think is taking increasing amounts of time by setting breakpoints at the beginning of GoView.PasteFromClipboard and GoDocument.CopyFromCollection.
Here’s a simplified version of the code that executes:
public virtual GoCopyDictionary PasteFromClipboard() {<BR> GoDocument thisdoc = this.Document;<BR> Object docobj = null;<BR> try {<BR> IDataObject data = Clipboard.GetDataObject();<BR> docobj = data.GetData(thisdoc.DataFormat);<BR> } catch (...) { ... }<BR> GoDocument clipdoc = docobj as GoDocument;<BR> if (clipdoc != null) {<BR> return thisdoc.CopyFromCollection(clipdoc, false, false, new SizeF(1, 1), null);<BR> }<BR> return null;<BR>}If the GetData call is what’s taking longer and longer, I can’t explain it, because the data ought to be staying the same between calls to EditPaste, hence the deserialization ought to remain about the same amount of work.
By the way, GoView.EditPaste starts and finishes its own transaction, so you don’t need to do so (unless you expect there to be document changes as a result of clear the view’s selection, which is highly unusual and not what I would recommend).
I have found that the delay is at
IDataObject data = Clipboard.GetDataObject();
docobj = data.GetData(thisdoc.DataFormat);
the IDataObject is retrieved ok and thisdoc.DataFormat indicates it is
using my ModelDocument, but it takes varying amounts of time to
“GetData”
Here is another clue… if I’m pasting to a large model document (ie:
has lots of GraphNodes and links) the data.GetData takes a much longer
time than if I’m pasting to small model document.
When I select and copy a single GraphNode, what is on the clipboard?
The whole source document + GraphNode / blank document +GraphNode /
just GraphNode? My ModelDocument has two layers (one for GraphNodes
and one for links).
GoView.CopyToClipboard constructs a new instance of your document, constructs all the same layers by calling GoDocument.MergeLayersFrom, and then copies the selected objects by calling GoDocument.CopyFromCollection. This new document containing a copy of the selection is what is serialized to the clipboard.
The clipboard should not be holding a copy of the whole source document. But perhaps your copying methods are somehow causing everything to be copied. Unlikely, I think.
I had interpreted your earlier explanation as indicating that you did not do repeated GoView.EditCopy()'s [i.e. Ctrl-C’s]. There was just a single EditCopy, and then repeated EditPaste’s which kept getting slower and slower. In this scenario the contents of the clipboard should not be changing and thus should not be getting bigger.
OK, just for fun, I created a document with 100,000 nodes and 100,000 links, with the nodes spread out in a rectangular array. That took a minute.
I selected a few nodes and links (I think 20) and did a Ctrl-C.
Then I repeatedly did a Ctrl-V. It went quite fast–too fast for me to get any idea of how long it took. After holding down Ctrl-V and letting the key autorepeat, I did not notice any slowdown in doing a paste, even after a few hundreds of EditPaste()'s.
I also ran the test you described. Single copy, multiple paste.
With a simple GoNode there is no problem. I also found that some
of my simpler GoGeneralNode derived (GraphNode) objects do not exhibit
the “bad behavior”. My question is how to figure out why GetData
is taking so long for particular GraphNode if the GraphNode can be
serialized and deserialized without error or delay to a file.
What is different about the clipboard? My GraphNode objects do
contain references to other objects, but I have tagged them all as
[NonSerialized].
I have no idea – it seems pretty mysterious, like a lot of Windows Forms internals.
But at least you have the code that we use, as I posted earlier, so you can experiment and time programmatically, rather than having to do things interactively.
I have found two things that appear to be causing my problem (ie: two
objects that when marked [NonSerialized] seem to allow multiple paste
with no delay). In one of my GoGeneralNode derived classes I
override CreateIcon with Meter derived class that contains IndicatorBar
object. In another of my GoGeneralNode derived classes I was
saving the port created in my override CreatePort() method for use in
my LayoutChildren override. In first case, I set IndicatorBar
[NonSerialized] and in second case I just search through .Ports
collection for the port I previously was saving. I can now cut
and paste without any delay. Does this make sense?