Shapes do not stay in given z-order after save and open

wapperdude · July 16, 2021, 07:37:45 PM

I tried a couple different things, most failed. But at one point in saving, Visio asked if I wanted to preserve Z-order. I said yes, but that made no difference. So, the clue is in the saving process.

The only, and very ugly, work-around I discover to be effective was to ungroup and then re-group. That did save correctly.

Would be nice if anyone else would try and verify this loss of z-factor when adding shape to group.

wapperdude · July 16, 2021, 08:21:04 PM

Final note:
I was able to narrow this down. If you drag and drop a grouped shape from a stencil, then add another/replace a shape to the group the "new" shape appears on top. That's normal. You can then subselect into the group and move the shape to the back. This again is normal. Save the document. Close the file. Re-open, and Viola! the z-order is incorrect. The new subshape is at the very top visually. Ergo, the problem.

Had the dragNdrop group been ungrouped and then regrouped (this is typically a bad idea/thing to do), then add new shape, send to back. Repeat save, close, open, and all is well.

I don't recall this being a problem in the past.

Paul Herber · July 17, 2021, 04:24:00 PM

Defo reproducable here in Visio 2016, but in V2010 it's ok.
I took one of my large grouped shapes, placed a rectangle next to it, selected all, added to group. In the Drawing Explorer, found the added shape (Sheet.26 in this case), Send To Back, saved file in VSSX format. Reopened file. New shape is back on top.
Had a look using my Utils -> Grouped Shape Report.
When the new shape is added to the group, it becomes Sheet.26 and is the last shape in the grouped shape list report.
Send to Back: report now shows Sheet.26 in position 1, i.e. it has been sent to back.
Save, Reload ...
Report now shows Sheet.26 back to being the last shape in the grouped shape list.
Now repeat in V2016 but save in .VSD format. All is ok. It is the VSDX format save that is ~~&%£@*&$~~ wrong.

wapperdude · July 17, 2021, 06:12:37 PM

@Paul Gerber: totally awesome dude!!!

wapperdude · July 17, 2021, 11:30:58 PM

Interesting addendum to Paul's findings.

First, I confirmed that VSD does get it right. But then, resaved the VSD file as VSDX. Right?!? After all, the VSD is now correct. Busted. The VSDX file still gets it wrong!!!

Visisthebest · November 15, 2023, 11:20:29 PM

Excellent investigation of a clear Z order issue with subshapes!

I wonder where Z order is stored in the XML of a VSDX file, this may be a way to fix it by editing the XML in the file.

Paul Herber · November 16, 2023, 08:27:26 AM

Each shape has a .index property, that is the Z-order.

Visisthebest · November 16, 2023, 09:09:16 AM

Yes I forgot Paul, I would be afraid to change the index number in a VSDX file's XML, maybe other data is referencing it or just the shape ID?

Can certainly try to experiment with it with a test file, who knows this might solve the issue.

Visisthebest · November 16, 2023, 11:03:08 AM

Ok so this new issue here: http://visguy.com/vgforum/index.php?topic=10233.0

Is related to this issue from 2021!

My problem is data graphics, when added to a group shape, are covered by the subshapes in the group.

What I just discovered is, after I save a VSDX and reopen, the order is fine again and the subshapes are covered by the data graphics!

So in my case saving fixes the issue, although it is not a very good fix. I will continue to investigate, also looking at the XML.