Announcements

Announcement: We’re aware of an issue affecting starting a new topic from category pages and creating new blog posts. New topics can still be started directly from the relevant board. Learn more here.

Automatically update blocks from central repositories

Automatically update blocks from central repositories

Anonymous
Not applicable
2,405 Views
5 Replies
Message 1 of 6

Automatically update blocks from central repositories

Anonymous
Not applicable

Hello


I just wanted to open a discussion about the best way to manage blocks at present and possible improvements to the way this is handled.

 


Easier Updating of Block Definitions

So a key request from my office would be to make it easier to keep blocks up to date against some kind of centralised repository. As far as I know this is only really possible at the moment through the design centre, a tool which I think is not commonly understood among my colleagues and relies upon the user knowing and understanding the file structure behind the block library.

The design centre seems clumsy for the purposes of simply redefining block definitions; perhaps principally because users also have to deal with a great deal of other parameters and subheadings to do with managing layers, styles and other drawings that have nothing to do with the one I am currently concerned with.

I would suggest instead perhaps a new window or tool that gives a clearer description of any block definitions in the current drawing, the repository from which they were drawn and a nice, obvious button to update a single block, array of blocks, or all blocks in drawing. With several different ways of inserting blocks, I think a clearer user interface for managing their definitions would be very beneficial.

 

 


Better Link to Repository

At the moment, there is from what I have seen a high risk of users modifying block definitions local to the file they are working on rather than modifying the central repository.

 

I believe this stems from the lack of clarity regarding where a block was intended to be linked to a central source and regarding the locality of block definitions when accessed through the block editor.

 

I see a few issues with the current setup:

 

1 - It is easy for a user to feel they are editing an external block definition based upon the new window created by the block editor

 

2 - A user may recognise blocks intended to be updated from the central source. They are therefore prone to editing the blocks with their own changes which may see changes lost if they attempt to update from the repository later on.

 

3 - A user is much more likely to edit the local block definition even if they are aware that there may be an external definition somewhere, because it is much easier and quicker to do. Simply double click and away you go, whereas to edit the repository you have to know where the block definition came from and how to update your local definition to match that of the library. This issue would be less likely to manifest if double-clicking a 'linked' definition took you straight into editing the definition within the library, though of course it may be useful to provide some notification that you are editing an external file so users don't inadvertently edit the library.

 

 

 

Next Steps

This is just a discussion really.
Perhaps somebody can notify me of better ways of doing things.

Perhaps somebody at autodesk will consider taken on these comments for future improvements.

 

Thanks

 

0 Likes
2,406 Views
5 Replies
Replies (5)
Message 2 of 6

Kent1Cooper
Consultant
Consultant

XREF such things in instead of INSERTing them, and when the central-repository version is edited, the changes will automatically update in all drawings in which they are XREF'd, and when someone double-clicks on one to edit it, they will be editing the central-repository source, rather than only within their current drawing [which you may consider dangerous -- good training is essential].

 

Or, if the central-repository location is added to everyone's Support File Search Path list [in the OPTIONS dialog box, Files tab], and if that is the only place where such drawings that become used as Blocks are located, any Block can be updated to agree with the current central-repository source version very simply, without the need to navigate to there or use the Design Center at all:

-INSERT

YourBlockName=

Yes

{cancel without inserting another one}

 

Note the hyphen before the command name, to use the command-line version, not the dialog box.  The name with equals sign following means "go look for a drawing with this name to use for this Block definition."  The Yes it to answer the question of whether to redefine it.  As soon as that has happened, the definition will be updated and all Insertions will reflect that, so the command can be cancelled [unless at the same time you want to Insert another].

 

A routine could easily be made to step through all Block definitions in the drawing and update them in that fashion, or it could be built to do so for only certain Block names, or there are other permutations possible.

Kent Cooper, AIA
0 Likes
Message 3 of 6

Anonymous
Not applicable

Thanks for the reply.

 

Regarding X-REFs
A good suggestion I suppose. It had crossed my mind but I had a feeling people would not be happy about your key X-REFs (for example architect's floor plans) being in the same space as say 100 blocks.

I am also not sure if dynamic features available with blocks can be implemented in X-REFs.

 

 

Regarding Insert via Command-Line

I haven't tested what you're describing, but if I'm understanding you correctly this requires re-inserting any and all blocks you wish to redefine.

I feel that this somewhat misses the points about the updating process being clunky and obfuscated for most users.

0 Likes
Message 4 of 6

Anonymous
Not applicable

Update:

 

Attaching a dynamic block file as an X-REF appears to lose it's dynamic abilities.
At least this proved true when I tested a simple block with two visibility states.

0 Likes
Message 5 of 6

dbroad
Mentor
Mentor

I use palettes.  The individual blocks are added to the palettes from within a host drawing, a type library, not by dragging drawing files themselves onto the palettes.  Folders can be secured by user and assigned rights.  Updating will be "semi-automatic" since you must right click on a palette icon and choose "redefine".  In my opinion, fully automatic updating across multiple projects is a recipe for disaster.  Anything like that would need to be scripted AFAIK.  Dynamic blocks would still be subject to being broken if the person editing them wasn't expert.

 

The palettes themselves can be created by opening a library file and using the create palette function of the design center or can be manually constructed by drag-n-drop.

Architect, Registered NC, VA, SC, & GA.
0 Likes
Message 6 of 6

RobDraw
Mentor
Mentor

Blocks were not designed to be used in this fashion.

 

It's my understanding that dynamic blocks will lose any instance properties and all will revert to the default values when updated.


Rob

Drafting is a breeze and Revit doesn't always work the way you think it should.
0 Likes