Author Topic: Loading Blocks should have the option of overwriting existing Blocks.  (Read 157 times)

Lar

  • Hero Member
  • *****
  • Posts: 2484
From what I can figure, if you load a Block (by pasting, merging or loading a Symbol that contains the Block) into a file that has a Block with the same name, the new Blocks will be loaded but will be defined like the existing Blocks.

What I would like to see is an option (either a global option or in the dialog when the loading is happening) to overwrite the existing Blocks.

I have an interesting situation where I created a file containing Blocks then later selected some stuff (that included Blocks), saved the selection to an external file, then loaded the external file as a Linked Symbol into another file (let's call this last one "File-C"). While working on File-C I decided to make changes to a Block in the Linked Symbol. So I closed File-C, opened the source file of the Linked Symbol and edited the Block. I saved and closed the source file then reopened File-C, expecting to see the changes in the nested Block, but it looked like the same old Block.

To make an even longer story short-er, what I finally had to do was use the Insert Manager to delete the Block, save and close File-C, then reopen File-C and finally the Block looked proper.

What caused all this was when I first loaded the Symbol into File-C, the Blocks it contained got loaded into the file as well. Then, even though I edited the Block in the Linked Symbol's source file, closing and re-opening File-C ignores the definitionsof any Blocks that have existing names and keeps the definitions of the existing Blocks. The only way to get the new definition to be acknowledged is to remove the existing definition from File-C.

Now, it was good that there were no un-nested Blocks in File-C because deleting the Block with the Insert Manager would have gotten rid of them. If there were un-nested Blocks I would have been forced to do it the old fashioned way and, instead of deleting the Block, paste in the original entities from the Block in the source file and re-defining them as the Block in File-C. This is not that difficult to do but it would be so much better to have an option that I can enable or disable as the situation calls for.

Lar

Rob S

  • Hero Member
  • *****
  • Posts: 4285
    • Construction Estimating Program for General Contractors
Re: Loading Blocks should have the option of overwriting existing Blocks.
« Reply #1 on: December 16, 2016, 09:11:39 AM »
Interesting

In theory symbols are stored totally in the symbol file and re-read into the main file when loading a drawing where they are referenced.

Blocks are stored in the current main file, no need to be re-read from any source file, thus portable.

However, if a symbol file contains blocks, I would say these should be re-read as part of the symbol, and not stored in the main file.

I think you might be talking about loading a symbol exploded, thus it is no longer a symbol, but becomes part of the drawing, is that correct?
User since Pro-design

Lar

  • Hero Member
  • *****
  • Posts: 2484
Re: Loading Blocks should have the option of overwriting existing Blocks.
« Reply #2 on: December 16, 2016, 09:52:25 AM »
I think you might be talking about loading a symbol exploded, thus it is no longer a symbol, but becomes part of the drawing, is that correct?
Well, to be honest I was talking about any of the ways of merging a Block into a drawing that already contains a Block definition with the same name. However, I have since tested a bit further and have discovered that if you paste in a block with the same name then "[1]" is appended to the name. However yet again, even further tests reveal that after pasting, if you go back and revise that pasted in Block, then re-paste it in this drawing, this 2nd pasted-in iteration of will also be named "Block [1]" will look like the first pasted-in Block [1]" and will not look like the revised Block in the other file.

... loading a symbol exploded, thus it is no longer a symbol...
Well, In my scenario the Linked Symbol was not exploded... but it doesn't matter if it was exploded or not. Either way the Block nested in the Linked Symbol takes on the definition of the existing Block definition.

Lar