This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Version 3.0.2027.23323 Attached the sample project. It's based off of your Group Nodes sample. Steps to reproduce: 1 - Drag a child node into the surface. 2 - the child node template has been modified to contain a FlowDocumentScrollViewer whose Document property is bound to a ViewModel property. 3 - Click the "Save to PNG" button which calls DiagramBitmapRenderer.Png.Render(this.ds, memoryStream); 4 - an ArgumentException occurs. I'm reporting this because we're having other seemingly related issues which we can't reproduce at the moment, related to some internal parts of your code treating the FlowDocument as a Visual and attempting to VisualTreeHelper.GetParent() on it. As soon as we find a way to reproduce these issues, I'll get back to you with proper repros. In the meantime, I'd like to confirm that you are accounting for these things in your code, since I had to jump thru several hoops to get the basic rich text feature working inside the surface. |
|
|
Hello, thanks for the repro project. When saving to png, the DiagramBitmapRenderer takes your diagram model and displays it in a new instance of DiagramSurface specifically for producing an image. This DiagramSurface is loaded with the same style resources that your main DiagramSurface uses so that everything looks the same. The problem here is that now there is a new DiagramSurface visual containing a second visual for each node which in your case will mean there are 2 FlowDocumentScrollViewer controls binding to the same FlowDocument instance provided by your node model. This is not allowed in WPF and causes the ArgumentException. I haven't worked with FlowDocument much, but from what I've read, it's best not to provide FlowDocument objects from the model, instead they are intended to be used within styles/templates, and the model should provide the data necessary to build up the FlowDocument. Doesn't look like FlowDocument provides a simple way of doing this though. The easiest solution to this that I can think of right now could be to store the contents that you want to display in the FlowDocument as a single string property on the node model. For example an xml formatted string that describes what is displayed in the FlowDocument. Then when binding this in the node style, have some kind of converter that can convert the xml string into the FlowDocument contents. The reason why I think this would be the easiest solution is because if your application has a save/load functionality, you're going to need to serialize the contents of the FlowDocument in one way or another when the user saves their modifications to the diagram (maybe you even already have a way to do this). Hope that helps! Let me know if you have further questions. -Jason Fauchelle |
|
|
Jason: Thanks for your response. With all due respect, it sounds to me like you're dodging the problem rather than providing a solution. Putting an IValueConverter between the VM and the UI would unnecessarily complicate our design, since we're using RichTextBoxes which allow direct modification of the FlowDocument itself, and then this gets converted to XAML by the XamlWriter and saved to disk. If I were to introduce an IValueConverter and store the XAML as a string in the VM, I'd have to use a solution similar to http://www.codeproject.com/Articles/66054/A-Bindable-WPF-RichTextBox This is not a good solution for our scenario, since it requires that the document be re-serialized on every key press or modification, which drags performance down. Instead, we only serialize on Save() and deserialize on Load(), and then operate against the FlowDocument object instances directly. the way we're binding right now is via a DependencyProperty that manually sets the RichTextBox.Document property upon change (since the RichTextBox.Document is not a DP and cannot be bound):
Notice that this code already contains workarounds for the errors caused by the diagram. However, as mentioned in the first post, we're having some other errors related to some parts of your code calling VisualTreeHelper.GetParent() on non-Visual objects (this means, classes that don't derive from System.Windows.Media.Visual) My point is that we need to make sure that you're contemplating and taking into account the possibility that FlowDocuments will exist within the Visual Tree of the Diagram (not as part of the Visual Tree itself, because they're not Visuals, but rather as "data" within certain Visuals) throughout your code, not only for screenshot rendering, but also for all cases where the Visual Tree is traversed/modifed/operated against, to prevent these exceptions. in the worst case scenario, if the FlowDocuments need to be cloned for whatever reasons, you could improve your code so that it does it when needed, and save all users of your framework from the nuisance of having to do it themselves. It'd be great if you can take this as a feature request / bug report and consider this situation throughout your framework, so that we can have our minds in peace that this scenario is actually supported. Let me know your thoughts on this. Thanks and regards. |
|
|
Hello, In short, no we haven't yet considered Flow Document support within the diagram. I'd like to point out that the issue with exporting the image is different to the other issues where our diagramming framework traverses the tree. In the case of traversing the tree, I'm sure that we can certainly improve the diagramming framework there. It should be as simple as detecting that an element is not part of the visual tree, and instead walk the logical tree. If I am able to reproduce this issue, I could release a fix for this within the next 48 hours. (If you can provide any steps to reproduce the tree traversal issue, that would help). The image exporting issue is a bit out of our control though. Since we need to create a new diagram visual bound to the existing diagram model, this can cause 2 node visuals to bind to the same FlowDocument instance. This occurs by applying the styles that you provide, which binds to your node model. We don't do any traversals here, just let WPF do its thing. It would be difficult to inject something here to check that a FlowDocumentScrollViewer happens to exist in a node style that binds to a FlowDocument property. Perhaps you could solve this exporting image issue with the cloning technique at your end? That may result in the user manipulating a cloned document in the rich text editor though. I assure you I would solve this issue at our end if I could come up with a way to do so. -Jason Fauchelle |
|
|
Jason: Thanks for your quick response. I understand that these are two separate issues, and I'm more concerned about the visual tree traversal issue, since we've been able to workaround the Document clone successfully. Unfortunately, I cannot provide steps to reproduce yet, this came from an end user and we've been unable to reproduce it in our dev machines. All I've got for now is the attached Stack Trace. I hope this helps. As soon as I manage to reproduce the issue I'll get to you with proper sample code. Thanks again |
|
|
Thanks for the stack trace. This was enough for me to reproduce the issue. I'll look into resolving this tomorrow and let you know how it goes. -Jason Fauchelle |
|
|
I've resolved this issue in the core visual tree traversal helper which should solve all FlowDocument issues related to tree traversal. This is certainly resolved in all the ways I could reproduce the issue in the repro you sent. This fix will be in the next nightly build. This will be available at around 1200 GMT and will be downloadable from your account page. Let me know if you have further questions. -Jason Fauchelle |
|
|
Jason, It looks like this nightly never got published... The last one is from Oct 22nd, and your message was Oct 24th. We are waiting on pushing a fix out to our customers until we can get this. Is it possible to get the updated build ASAP? Thanks, Reed |
|
|
Hi Reed, Apologies for not getting onto this earlier. We've resolved the build issues, so the nightly builds should be up to date at 1200 GMT -Jason Fauchelle |
|
|
The latest nightly build is now up to date. -Jason Fauchelle |
|
|
Thanks Jason! We just downloaded it, and so far, it's working properly. We'll let you know if we run into more issues with this. |
|