Containers = The New Group?

[Paul Herber]

I wonder if containers are being positioned to be the user replacement for grouping shapes. Adding shapes to a container doesn't break shapes in the same way as grouping them can (as far as addons are concerned - i.e. certain addins might not be able to recognise the shapes the addin is meant to work with when the shape is part of a group, though the org chart addon does recognise this and prevents org chart shapes from being grouped).

[wapperdude]

Obviously it's a feature of grouping that I've never used...but, I can't recall even lamenting the fact that I'd like to have it.  I found grouping to have two primary uses:  1.) to make complex shapes from simpler ones, and 2.) to gather a group of shapes to preserve their spacing relationships.  But, that's all I've ever needed from it.  It's a simple world that I live in.

I'll refrain from further remarks about the ribbon...      

Wapperdude

[gwideman]

Obviously it's a feature of grouping that I've never used...but, I can't recall even lamenting the fact that I'd like to have it.  I found grouping to have two primary uses:  1.) to make complex shapes from simpler ones, and 2.) to gather a group of shapes to preserve their spacing relationships.  But, that's all I've ever needed from it.  It's a simple world that I live in.

Yes, that's what we frequently use grouping for.  It's mostly suited for (1). 

But grouping is poor for (2) because as a side effect it changes the coordinate system for those grouped shapes (not to mention installing formulas that make size relative to the group) and it also buries the shapes one layer deeper in the Automation object model.  So it creates all sorts of extra work for any addon that really just wants to deal with shapes that are direct members of Page.Shapes, and/or wants to proceed assuming that shape locations are relative to the Page.  And it messes with line routing.

So it's for (2) that containers make a lot of sense. 

But now that we have containers, I want containers that can have non-rectangular shapes, because that would be highly useful for partitioning diagrams of systems with lots of boxes.  Even the ability to go to a big fat "L" shape would be a useful advance.

Not that this move is particularly useful, but I did notice that you can set the Angle on a container, after which it doesn't behave so well  .

-- Graham

[vojo]

but the argument for 2) doesnt hold (alot) of water
A) if the intent is to aid the addon for a diverse world of shapes to contend with, wouldnt it be better to have the add on have a function that explores the shapes in play.   I.e. assuming I had
    containers, who is to prevent some crazy user like me from having a group of containers in a single group (why...maybe I was an idiot).   Usually, for networking and storage protocols, the
    initiator (add on) explores the target (set of shapes) to figure out what is there and what is feasible.   Just cant blindly trust that "gee containers present....good to go"
B) I could see some value possibly on the line routing point...though I never use this feature....I could see somebody relying on it to lay out given set of shapes.
    (Although here too, the VBA for automatic routing already has to explore the set of shapes anyway and probably builds a map internally before it can decide where to put shapes and lines....
     all we are talking about with containers is one less math translation during exploration).   Frankly, adding 2 cells that give absolute location or location relative to page would be far far more
     useful than containers (if new shape, thus new cells present, great....if not, add them in new section or add to user cells and call them something wild to stay clear of any current user
     cell names) gives the best of both worlds  - supports the hubris of containers (as is or via cells) and allows users to do additional  stuff (try lining up a corner of a square to some point on a
     circle using just formulas in shape sheets...loctoloc doesnt cut it).

MS needs to think more about how to exploit the unique attribute of exposing the precision of visio (not aware of other tools - libreoffice, sketchup, etc - that give you that ability)
vs trying to hide that attribute behind arcane enhancements.   The more that the precision is hidden the more visio becomes powerpoint.

Obviously, you can tell this stuff works me up ;-)