Project Standards: MVB View Blocks synchronization?

[Anonymous]

Can someone else please confirm that (physical) changes to View Block
definitions
referenced in a Multi-View block, do not synchronize?

and my next question, obviously,
is: "why not?"

[Anonymous]

They do not.

Why - great question...


--
paul


Paul F. Aubin
Paul F. Aubin Consulting Services

Current book editions, available now:
Mastering Autodesk Architectural Desktop 2007,
Autodesk Architectural Desktop 2007: An Advanced Implementation Guide
(Second Edition)
Mastering Autodesk Revit Building
Mastering VIZ Render 2006 - A resource for Autodesk Architectural Desktop
Users

Buy books and download resources online at:
www.paulaubin.com

[Anonymous]

Corey A. Layton wrote:
> Can someone else please confirm that (physical) changes to View Block
> definitions
> referenced in a Multi-View block, do not synchronize?

Yes. About the only solution I have come up with for this is to rename
the referenced view block in your standards drawing.

Next time things synchronize, your mvblock def uses a 'new' view block,
and it gets imported. I haven't used this on any block with attributes,
so I couldn't tell you if those play nice in the process...

> and my next question, obviously,
> is: "why not?"

Goes along great with the question of "Why don't Project *AutoCAD*
standards actually let you *fix* any problems?"

--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Paul F. Aubin wrote:
> They do not.
>
> Why - great question...

thanks for confirming, Paul.

as to why,
there are three possible scenarios that I can think of:

1. No one ever considered it.
2. Project Standards (synchronization) does not apply to AutoCAD entities
(Blocks).
3. It intentionally does not synchronize because, it's possible, that View
Blocks referenced in a Multi View Block definition might be stand-alone
block instances in the dwg as well. And maybe you don't want those to
synchronize?

On the particular Job that I'm working on, the building room numbering
standard is 4-digits (vs. the typical 3-digit), plus some rooms have
Alphabetic prefixes and/or suffixes; so the number is a pretty long string
in some cases.
I had the bright idea to modify my Door Object Schedule Tag View Block to be
a wide elipse vs. a circle to contain the larger string; add it to my
Project Standards dwg (synchronization priority #1, my *Enterprise Standards
DWg is priority #2...); and then it will (in theory) syncronize my other
Views in the Project. 😞

[Anonymous]

Corey A. Layton wrote:
> Paul F. Aubin wrote:
>> They do not.
>>
>> Why - great question...
>
> thanks for confirming, Paul.
>
> as to why,
> there are three possible scenarios that I can think of:
>
> 1. No one ever considered it.
> 2. Project Standards (synchronization) does not apply to AutoCAD entities
> (Blocks).
> 3. It intentionally does not synchronize because, it's possible, that View
> Blocks referenced in a Multi View Block definition might be stand-alone
> block instances in the dwg as well. And maybe you don't want those to
> synchronize?
>
> On the particular Job that I'm working on, the building room numbering
> standard is 4-digits (vs. the typical 3-digit), plus some rooms have
> Alphabetic prefixes and/or suffixes; so the number is a pretty long string
> in some cases.
> I had the bright idea to modify my Door Object Schedule Tag View Block to be
> a wide elipse vs. a circle to contain the larger string; add it to my
> Project Standards dwg (synchronization priority #1, my *Enterprise Standards
> DWg is priority #2...); and then it will (in theory) syncronize my other
> Views in the Project. 😞

I'll add to the list, one that I *intentionally* took advantage of this
'feature'...

4. I changed the Annotation Plot size in our template files (partners
wanted 90% of our tags bigger), and altered the remaining 10% View Block
defs, in order to keep the *same* relative scale. Drawings that already
have been set up with a different Annotation Plot size, I *want* them to
keep using the older block def. If it updated the block def, all of
these tags would now be too small.


--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Brian Winterscheidt wrote:
> 4. I changed the Annotation Plot size in our template files (partners
> wanted 90% of our tags bigger), and altered the remaining 10% View
> Block defs, in order to keep the *same* relative scale. Drawings
> that already have been set up with a different Annotation Plot size,
> I *want* them to keep using the older block def. If it updated the
> block def, all of these tags would now be too small.

this is something that I would have handled with my Hierarichal
Enterprise/Project Project Standards setup.

Just add the MV block styles you didn't want to change,
to the Project Standards.dwg for the legacy Projects (*.apj).
Then modify the MV Block Style definitions in the Enterprise Standards.dwg
and new Projects, going forward; would realize the change...

[Anonymous]

Corey A. Layton wrote:
> this is something that I would have handled with my Hierarichal
> Enterprise/Project Project Standards setup.

Yours must be set up backwards from ours... Our "project standards" are
at the bottom of the food chain. If there is a newer version higher up
the chain, you're getting it. Users are told to *never* modify anything
from the office standards, but 'copy and assign' instead, and *then* add
to Project Standards.dwg

I guess we could have reordered the standards for all 'legacy' jobs, but
that gets messy, as I've never had any luck getting the 'synchronize
standards' options in the CadManager menu to work to synch stuff from
one standards drawing to another. And now you have older stuff higher
up the chain than the newer stuff, and it prompts you every time about
what you want to do with those objects...


--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Brian Winterscheidt wrote:
> Yours must be set up backwards from ours... Our "project standards"
> are at the bottom of the food chain. If there is a newer version
> higher up the chain, you're getting it. Users are told to *never*
> modify anything from the office standards, but 'copy and assign'
> instead, and *then* add to Project Standards.dwg

just to clarify:

"Enterprise Standards" = typical company standards, server-based (single
dwg), priority #2. Full of styles and definitions.

"Project Standards" = project-specific deviations from the company
standards, server-based (multiple dgw's, one per project), priority #1.
Empty of Styles and defintions by default.

[Anonymous]

Corey A. Layton wrote:

> just to clarify:
>
> "Enterprise Standards" = typical company standards, server-based (single
> dwg), priority #2. Full of styles and definitions.
>
> "Project Standards" = project-specific deviations from the company
> standards, server-based (multiple dgw's, one per project), priority #1.
> Empty of Styles and defintions by default.

as I said, yours are backwards from ours.

Our setup:

"Enterprise Standards" = typical company standards, server-based
(currently multiple dwgs, might migrate to single dwg for 08), priority
#1. Full of styles and definitions.

"Project Standards" = project-specific deviations, server-based, one dwg
per project, priority #2. Empty by default, except for a few things
that got in there somehow, and I can't get rid of. Need to simply
replace the file in the template project...


Biggest difference between the two is that in your office, someone can
modify, for example, the office-standard CMU material for their own job.

Here, you would have to create a differently-named material in order to
customize it and have it stick. You better have a pretty good reason
for changing it, and you *aren't* going to have it named the same as an
office standard, because it *isn't* once you change it.


--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Hi Brian,
Sounds like your system has merit. I especially like copy style and assign
and use that on my projects. With your technique(enterprise #1), however,
you must be fairly disciplined not to make significant enterprise changes.
Otherwise, what would prevent some changes from interfering with projects
already partially built? I would think that it could also interfere with
the fidelity of archival projects (record documents). Right?

"Brian Winterscheidt" wrote in message
news:5536666@discussion.autodesk.com...
Corey A. Layton wrote:
> this is something that I would have handled with my Hierarichal
> Enterprise/Project Project Standards setup.

Yours must be set up backwards from ours... Our "project standards" are
at the bottom of the food chain. If there is a newer version higher up
the chain, you're getting it. Users are told to *never* modify anything
from the office standards, but 'copy and assign' instead, and *then* add
to Project Standards.dwg

I guess we could have reordered the standards for all 'legacy' jobs, but
that gets messy, as I've never had any luck getting the 'synchronize
standards' options in the CadManager menu to work to synch stuff from
one standards drawing to another. And now you have older stuff higher
up the chain than the newer stuff, and it prompts you every time about
what you want to do with those objects...


--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Doug Broad wrote:
> Hi Brian,
> Sounds like your system has merit. I especially like copy style and assign
> and use that on my projects. With your technique(enterprise #1), however,
> you must be fairly disciplined not to make significant enterprise changes.
> Otherwise, what would prevent some changes from interfering with projects
> already partially built? I would think that it could also interfere with
> the fidelity of archival projects (record documents). Right?


For archival projects, we are being careful to set the Project Standards
Synch to Manual prior to archiving, so that it *doesn't* happen
automatically. There would be nothing to prevent a user from manually
synching the project, other than it is a will-full (and hopefully
intelligent) act to do so. We also save PDF and hard copy of the record
drawings.


--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Brian Winterscheidt wrote:
> Here, you would have to create a differently-named material in order
> to customize it and have it stick. You better have a pretty good
> reason for changing it, and you *aren't* going to have it named the
> same as an office standard, because it *isn't* once you change it.

the only problem with that scenario that I see is that,
if you want to project-deviate a standard Style or Definition,
that is placed regularly via Tools;
the name-change screws up that workflow.

(consider my Door Tag example in an earlier reply to P.Aubin...)

Do you create a new Project-based Tool, as well?
Seems like more steps than I'd be willing to administer...

[Anonymous]

Doug Broad wrote:
> copy style and
> assign

could someone summarize how this feature is (inteligently) used?

[Anonymous]

Corey A. Layton wrote:

> the only problem with that scenario that I see is that,
> if you want to project-deviate a standard Style or Definition,
> that is placed regularly via Tools;
> the name-change screws up that workflow.
>
> (consider my Door Tag example in an earlier reply to P.Aubin...)
>
> Do you create a new Project-based Tool, as well?
> Seems like more steps than I'd be willing to administer...

I tell them to use 'Add selected' instead of a tool. 😉

--
Brian Winterscheidt
LWPB Architecture
Oklahoma City, Oklahoma

[Anonymous]

Let's say I want to make a change to a wall style. I have a wall in place but it doesn't
do what I want. I also want it to have a different name from the OOTB styles so it
doesn't conflict. Right click on the wall/door/whatever and choose "copy and assign
style". You go straight to the style manager and can make changes to the new style
without adversely affecting preexisting work. (I generally change the style name to be
more descriptive to the context)

If no walls are in place, then drag-n-drop into the drawing and then right click and
proceed.

For walls at least, things are more complicated than just that due to the need to change
endcap styles but that gets me started.

"Corey A. Layton" wrote in message
news:5536787@discussion.autodesk.com...
Doug Broad wrote:
> copy style and
> assign

could someone summarize how this feature is (inteligently) used?

[Anonymous]

I hope that was an intelligent example. 😉

"Doug Broad" wrote in message
news:5536904@discussion.autodesk.com...
Let's say I want to make a change to a wall style. I have a wall in place but it doesn't
do what I want. I also want it to have a different name from the OOTB styles so it
doesn't conflict. Right click on the wall/door/whatever and choose "copy and assign
style". You go straight to the style manager and can make changes to the new style
without adversely affecting preexisting work. (I generally change the style name to be
more descriptive to the context)

If no walls are in place, then drag-n-drop into the drawing and then right click and
proceed.

For walls at least, things are more complicated than just that due to the need to change
endcap styles but that gets me started.

"Corey A. Layton" wrote in message
news:5536787@discussion.autodesk.com...
Doug Broad wrote:
> copy style and
> assign

could someone summarize how this feature is (inteligently) used?

[Anonymous]

Doug Broad wrote:
> I hope that was an intelligent example. 😉

ok, I get it now.

It's sort of like a macro,
that compresses the normal steps required into a single click (or two...).

Not anything new, necessarily feature-wise.
Just a handy convienience?

Did I get that right?

[Anonymous]

Right. Just a convenient shortcut.

"Corey A. Layton" wrote in message
news:5536922@discussion.autodesk.com...
Doug Broad wrote:
> I hope that was an intelligent example. 😉

ok, I get it now.

It's sort of like a macro,
that compresses the normal steps required into a single click (or two...).

Not anything new, necessarily feature-wise.
Just a handy convienience?

Did I get that right?

[Anonymous]

Actually it's working great for me. I've used the system to update light fixtures to get rid of the circles, and to redraw furniture. The multi-view block has to be in the drawing, not just the block reference. You have to remember to "version" the MVB in the standards drawing and save it.

We have a client that wanted the titleblocks to be blocks instead of xrefs. We can use the same system to update a project specific titleblock accross the entire set using a project standard drawing and using synchronize project command.

--
Matt Jackson
myCADD Consulting
http://www.myCADD.com

[Anonymous]

Matt.Jackson wrote:
> Actually it's working great for me.

If I have a drawing in a Project,
and I make a change to a View Block;
I save,
and then 'Update Project Standards from Current Drawing'.

Then open another dwg in the same project,
with a pre-existing instance of the revised MV BLock,
and 'Synchronize Drawing with Standards...'

and I get nothing. 😞

does your method vary?