Best way to reference default shape information?

[kennyj]

Hello everyone,

I'm working on a template and shapes for layout of various types of cabinets, etc. in residential homes.
I'm trying to add as much intelligence into the shapes as possible, to make
using the template as simple as possible for its users, who are cabinet & shelving designers.

This is kind of a two part question, and I think it makes sense to have it in
one single thread, but if not, please let me know and I'll be happy to revise
it into two threads.

The first question is whether or not my approach makes sense, and the second
is, if so, how do I actually implement it.

The Question of Method
In considering that each house can have one or many ceiling heights, etc; and
each room within the house may or may not share preferences (colors, styles, etc.),
I'm thinking of using various master shapes to contain default shape data, which
can then inform or be overwritten by individual shapes, and I'm wondering:

• Is this a good idea, or problematic?
• Is there a better way or best practice approach I'm not aware of?

And then I'm sure I'll have some 'how to' follow up questions.

So, for instance, data-shapes might include:
User_Defaults: with properties such as ceiling height, cabinet construction & material preferences, etc.
House_Defaults: Initially matches User_Defaults where appropriate, but options are set for the specific house.
Room_Defaults: Initially inherits House_Defaults, but changeable based on specific room requirements

Visible Furniture Shapes, such as walls, and various Furniture Components: Inherit properties from Room, unless overrided.

Perhaps each project would have a hidden page containing an instance of each of the master shapes.
When the project is first created, the user would be presented with the House_Defaults properties, based from the User_Defaults shape, and asked to confirm them or make any desired changes.

Each drawing page would then be associated with a room, and have it's own drawing_defaults shape, which in turn would inherit properties from the house, until changed.

Perhaps on creation of each page, the user is presented with the room defaults, and is able to change them at will then or later.

Each furniture component shape, when dropped on the page, could then inherit certain properties from the room_defaults shape, until changed.

Perhaps any change to a default property on a furniture shape, would allow an option to change the room_default shape if desired, which in turn could potentially have options to change only this shape, update all of the relevant shapes on the page, or update all future shapes in the room, or in the house.

For example:
Room_Ceiling_Height = 92 in.
Cabinet_Top_Shelf_height = 80 in.

Therefore, any hanging cabinet dropped on this page, would self align to the 80 in. top,
and if it were a tall floor based cabinet, the cabinet panels would automatically adjust their
height to 80 in., etc.

whereas another room in the same house, might have defaults set at:
ceiling height = 108 in.
cabinet height = 96 in.
and the same cabinet shapes dropped on that page would behave differently.
 
If the method is good, then How to?

How do I tell a shape that is being dropped on a page, to reference a hidden shape, presumed to be present and thereby reference shape data and/or user-data of that shape?

Would this require VBA?

Would somebody possibly sketch out the basics or point me in the direction of what to research/study? (I"m a Noob to VBA)

Any other general advice?


Thanks!
[/list]

[Yacine]

Hi Kenny,
what you describe is feasable. I included a visio drawing showing how to set up such dependencies.
One main (background?) page gets the basic data.
In order to be able to set individual data to the single pages (rooms), they need to have the same data rows as the main page. A VBA macro does this for you on the pageadded event. (Ckeck the macros of the file).
The shape data of the single pages reference the main data. They can be overwritten, but also reset to the original values. (Check the actions section of the shapesheet)

The same principle applies to shapes (or masters). (Here check also the ondrop cell of the events section)

This said, I would further recommend a VBA driven solution, because it is better maintainable.
Instead of having the shape data hard coded in the template and the masters, it might be better to set their behaviour and data on creation. You don't know right now what wishes you and your users may have in the future. Modifiying dozens of masters manually will be cumbersome or even impossible.

Highly recommended is also a possibility to identify your shapes. Add at least a unique tag to your masters (eg Shelf123), in order to be able modify/replace them when needed in future. You could also add a hierarchy in the shapessheet (eg furniture, shelves, shelf123), but this is not mandatory because you can replicate that behaviour in VBA as well.

HTH,
Yacine

PS: Some further info http://visualsignals.typepad.co.uk/vislog/2012/06/using-page-shape-data-in-visio-master-shapes.html

[kennyj]

Wow - Thank you so very much, Yacine! I'll study this carefully, then post back.

-k

[kennyj]

This said, I would further recommend a VBA driven solution, because it is better maintainable.
Instead of having the shape data hard coded in the template and the masters, it might be better to set their behaviour and data on creation. You don't know right now what wishes you and your users may have in the future. Modifiying dozens of masters manually will be cumbersome or even impossible.

Highly recommended is also a possibility to identify your shapes. Add at least a unique tag to your masters (eg Shelf123), in order to be able modify/replace them when needed in future. You could also add a hierarchy in the shapessheet (eg furniture, shelves, shelf123), but this is not mandatory because you can replicate that behaviour in VBA as well.

Thanks again, Yacine, for this very useful/helpful reply. The examples are very clear and easy to follow.

I'm trying to fully understand this last 2 paragraphs. They sound very reasonable and feel right, but I want to make sure I completely 'get it', so I don't create trouble for myself later on.

Can you give me a simple hypothetical instance or two, to illustrate what you mean about using a VBA driven solution rather than hard coding the template / masters vs how I might realize down the road that I'm stuck manually modifying dozens of masters? It's probably completely obvious, but I'm not fully understanding.

By tagging, do you mean, simply assigning, for instance, user.shape_catagory = shelf, user.shape_type = shelf123?

And then if/when some desire becomes known related to all shelves, or all shelf123's, then use VBA to cycle through all related masters to update them according to the new information/feature/etc?

But since that would still be hard coding info into the masters, etc; and only using VBA to modify them, I'm trying to also better understand how you would use VBA differently to avoid hard coding into the shapes/templates.

Could you offer further enlightenment on this? I have more aptitude than experience, so I really appreciate the help

Kenny

[Yacine]

Sorry Kenny for the time I took to answer.
Actually, yes you got it right about the last paragraphs. And sorry, the examples you're asking for are not so easy to demonstrate.

But I'll try at least to answer your question by one of my anecdots of my Visio experiences.

Some years ago, we built up a library of shapes symbolizing pipe fittings, where each shape in the stencil represented a very specific part, with it's SAP ident, description, geometry and so on. We did not prepare any possibility to update the shapes by Excel or Access data. If I would guess, I would say that we used that library for 1 or 2 projects at the most. That project was dead before it really began. As soon as we had to change data, we realized that we had to edit the masters one by one to update them ... and postponed that work to ... eternity.

In later developements we took great care to implement easy "maintenance ports" for every repetitive possible task:
- the shape geometry, where the final geometry of the shape is a combination of different geometry sections (e.g. we separated valves in their bodies, their actuating parts and their position switches and setup the final valve by means of some simple macros)
- the data section, which is mainly controlled by Excel-Sheets or Access-DBs (Here we set  the final SAP-Data only at editing time from tables, instead of having them hard coded in the shapes)
- etc.

In the solutions we use, we still expect our users to click control elements to update the data of their shapes. But you can also think of solutions that would be triggered by the "on drop" event, so your users  are forced to run through a certain setup process.

(Visio is such a wonderful tool. You'll recognize that you're more limited by your imagination, than by the capabilities of the application.
It's up to you, to work out the best way to get the tasks done.)

[kennyj]

Thanks again, Yacine - that is helpful.

-k