Parent/Child Shapes and ZIndex problem

Hi,

We're evaluating Mindscape WPF Diagrams and, so far, we're getting really good results. There is just one problem regarding Shapes’ ZIndex that is blocking us.

We're creating a WPF Diagram based on existing ViewModels, which has some relationships between elements, like connections and parent/child relationships, so based on the NodeGrouping sample, we created our own parent/child models & shapes. Also this meens that shapes are not created from a toolbox, they’re created programmatically.

The problem appears (in specific scenarios) when adding a child shape (in the images, named Level2B) to a parent (See image BeforeAdding.png). Sometimes, the siblings (or siblings’ children) of this new child, disappears (See image AfterAdding.png).

Specifically, they don’t disappear, but they’re hidden behind the parent’s shapes. Taking a look at ZIndex property of the hidden shapes (using Snoop), they're set to -1 when the problem appears (See image ZIndexAfterAdding.png). Just before adding the new child shape, the ZIndex was correct and greater than 0 (See image ZIndexBeforeAdding.png).

See also image Snoop3DView-TestProcessorBehindLevel2.PNG to see a 3D representation of the Shapes position (ZIndex).

We've tried different alternatives to fix the problem, we've checked and tested all other posts related with ZOrder/ZIndex problems but we cannot find a solution. Also, we're using one of the latest Night Builds of V3 version and the problem persists.

Do you have any idea about what could be happening? Do you know when ZIndex is set to -1 by the Framework? Any help is appreciated.

A side note, we're working on a Visual Studio plugin, the Surface is hosted on a Visual Studio Document Window, but we don't think that can be a problem.

Thanks, Ezequiel

Hello Ezequiel

Thanks for evaluating our diagramming framework and pointing out this issue.

This was a bug on our end which I have reproduced and resolved. The fix for this will be in the next nightly build which will be available at around 1200 GMT (about 11 hours from now). Here is the link for convenience: http://www.mindscapehq.com/products/wpfdiagrams/nightly-builds

Jason Fauchelle

Thank you Jason for your quick answer! We're really happy with the support we get from you. I could check that the provided fix it's working well for the described scenario.

Unfortunately, there is a specific scenario where we're still facing ZIndex problems:

As I said previously, we're creating nodes programmatically based on user interactions with our Domain’s ViewModels. We use Mindscape WPF diagrams to create a visual representation of them. There are scenarios where some operations on our Domain’s ViewModels are represented by creating several shapes on the diagram, at the same time. In those cases, we create the shapes programmatically, all at once, adding them to the Diagram.Nodes collection, then the diagram is automatically refreshed showing the new shapes. One of this scenario is for example: Adding a child (with children) to a parent. That specific scenario is not working for us.

I'll describe the scenario following the previous example: Once the Level2B node is added, everything is working fine using the latest nightly build containing the Jason's fix (See image PreviousBugFixed.png). After that, if child elements are added to the Level2B node (which is already created) everything continue working as expected (See image BeforeComplexAdding.png).

Now, if a use case where we need to add a child (with children) to a parent is executed, it's causing ZIndex problems on the diagram (See image AfterComplexAdding.png). In the image, you can see that the Child of Level2B are hidden (ZIndex = -1) and the new Child with children (Level2C) is also hidden. However, the new Level2C's children are displayed correctly (Test3Sender and Test3Processor).

A 3D view of the WPF Elements using Snoop can be shown on image Snoop3DView-HiddenElements.png.

Note: Taking a look at all Shape's ZIndex using Snoop, these 3 entities are the only which ZIndex are -1.

I hope the description its clear enough to get some help from you. Maybe it’s useful if we’re able to understand what it's going on with ZIndex when using parent/child relationships. With a better understanding we can check/fix the problem ourselves.

We really appreciate your help, and we hope you can take a look at this.

Ezequiel

Hi,

We continued trying to fix this problem during the week, but unfortunately, we couldn't find a fix or workaround. We're currently block, we don't know what else we can try to make it work.

We'll really appreciate any help regarding this issue, since it's the only remaining thing on our implementation but it's really annoying. We cannot ship until we fix this problem.

Thanks!

Ezequiel

Hello Ezequiel

Apologies for the lack of response last week. I will be back from a vacation tomorrow so will be able to look into this for you soon. This issue is something we'll be able to fix at our end.

Jason Fauchelle

No problem Jason, I hope you enjoyed your vacations!

Let me know if you need more information!

Thanks!

Ezequiel Sculli

Thanks for your patience Ezequiel

Unfortunately I was unable to reproduce this particular scenario. Using the fact that the incorrect nodes have a ZIndex of -1, I have added a new piece of code in the ZIndex logic in the only place that I know this can happen. This will be available in the next nightly build, but I can not guarantee that it will fix the problem as I could not reproduce it. If the problem still exists, I will need you to send me a repro project so I can investigate this further. You can send repro project to me directly at jason@mindscape.co.nz

Jason Fauchelle

Once again... It seems you fixed my problem Jason, even without being able to reproduce it. =)

Thanks again, I really appreciate your help! I'd let you know if something else appear but so far it's working really well!

Excellent, Glad to hear it is all working well now!