[V8i SS3] Avoid auto cell renaming when saving to DWG

Need a solution how to avoid automatic renaming of duplicate cells. The cell in attached file UDVENT is correctly created using ByLevel/ByCell attributes but still when converting DGN (normal) cells to DWG(shared cells) it is renamed to UDVENT1, UDVENT2, etc. This is wrong behavior as cell geometry is identical. ByLayer/Byblock symbology is AutoCAD compatible so cells shouldn't be renamed.

Even if cells are different there is need to avoid automatic renumbering and ask user how to solve this issue. MS_RESOLVESCNAMECONFLICT variable doesn't help in this case.

CellNameConflict2DWG.dgn

Parents
  • ByLevel/ByBlock is not the cause of renaming - it is actual levels that are different. The elements in one cell are on level 1_UDTK_ELEM_VENT_####_#, but those in the other cell are on level 2_UDTK_ELEM_VENT_####_#. If both cells must be converted to one single shared cell definition, which is essentially what DWG save has to do, only on level can be used. It is not obviously to me which one to be correct. You are right that prompting you to select a correct level resolves the conflict for this particular file, which has only two cells. But I suspect that it may apply to general cases, files with lots of different levels, different colors, tags, etc, etc. Prompting users to resolve conflicts during a save as process, worse yet during a batch conversion, is unlikely a welcome solution. Keeping content unchanged but renaming them is on the safe side. At least cells can display correctly after the conversion. In your particular case, if you can create shared cells prior to saving as DWG, that would be the best way around this problem. Because you would know exactly which level to use for elements in a shared cell definition. When you create the cell definition, you just need to turn on the toggle "Use Shared Cells". Everything else is the same as far as creating a cell goes.



  • If both cells must be converted to one single shared cell definition, which is essentially what DWG save has to do, only on level can be used. It is not obviously to me which one to be correct.


    Both levels are correct. See CellNameConflict-expected-result.dwg file for expected result when saving to DWG. Shared cells are unmanagable in DGN environment, cause lot of issues and would like to avoid using them.

    Regarding prompting users to resolve conflicts I would expect that MS_RESOLVESCNAMECONFLICTS or similar variable would be honored when saving to DWG. Need something like MS_RESOLVENCNAMECONFLICTS (where NC stands for Normal Cell) variable to control how to resolve conflicts. But I see that it could be a more complex task when saving as require to compare which normal cells are identical and could be merged as one SharedCell and which are not.

    CellNameConflict-expected-result.dwg

  • What you have done in your desired DWG file is to have re-designed your normal cells in file - you have changed the levels of the circle and line elements of both normal cells to level "0". This result has the same effect as to the workflow of prompting you on the level conflict - in this case you'd have selected level "0". By changing levels of all the elements in a cell to level "0", you certainly have resolved the level conflict across multiple cell definitions. While this level change works for you, I suspect it to work for all users. It is not just level - tag, line style, fill color, etc, are all needed to be compared and resolved before a cell definition can be shared. I'm not sure how a configuration variable can really help in resolving all of these conflicts. I'm thinking perhaps a new option in DWG Save As may help: a new option that allows user to create single block from duplicated cells without checking for conflict at all, i.e. simply assume all cells under the same name are identical. When this option is turned on, all normal cells having the same name will be using the same shared cell definition after saved as DWG. This option would have an effect of "first come first serve" - the first cell in file would win. All other cells would share the same definition of the first cell found in the DGN file. This option would work for your case, and perhaps as well as some other user's cases. But an obvious drawback is that, when you get a DGN file you do not know for sure that all normal cells having the same name indeed can be shared with a same definition, you risk to create a DWG file with unexpected shared cells.



  • I tried various options when saving to DWG like [Try to] Create Single Block for Duplicated Cells and Create Block Entities with “By Block” Properties but none of them works as expected. These options are not good enough and doesn’t create single DWG block even if cells are identical(geometry) but only placement level differs. Also if Cells are placed using Relative option they are not treated as identical but should as it is how blocks in DWG works.

    In my opinion if the cells which are identical, uses ByLevel attributes and only Level differs then they are compatible with AutoCAD ByBlock and should not be renamed. The intelligence of „Create Single Block for Duplicated Cells” option can be improved to avoid creating multiple shared cell definitions in these cases. Also option to use cell definitions from DWG seed file would help to solve naming conflicts in case normal cells are not identical but should be replaced by only one definition. For now I see only option is to use shared cells but it has lot of drawbacks and it is inconvenient.


    BTW it is not clear Insert Layer for Normal Cells option should be used. If I set this layer to 0 then all cell instaces are placed in layer 0 and cell definitions are in original levels not useful at all.

  • I'm not sure what drawbacks and inconveniences you have encountered by using shared cells, but if you have found difficulty to create a single shared cell definition that can represent both of your normal cells, chances are that DWG save process will not be able to do any better. This is mainly because at the root of the issue is a concept mismatch - a normal cell is completely defined by itself whereas a shared cell is only an instance of a cell definition which may have many other instances.

    Let's take a look at a generic example, two normal cells using the same name with identical geometry. One cell has a circle on level 1 and a line on level 2, the other has a circle on level 3 and a line on level 4. Geometrically, the circles and lines are equal. They also have the same attributes, including ByCell/ByLevel symbology as you have emphasized. The only difference is level. Suppose you were to create a single shared cell that can represent both cells., you must change the levels one way or the other. There is no way you can keep all 4 levels the same in the single shared cell definition. If you were to ignore the level difference, then you'd get a single cell with a circle on level 1 and a line on level 2, or one with the circle on level 3 and line on level 4. But you cannot have all 4 levels, unless you have two shared cell definitions, which is essentially what DWG save would do.

    The Insert Layer option does not apply to your case - it is used for those who want to force shared cell instances on layer "0" when saved as DWG. It does not change definition - the definition must come original normal cell definition.



  • I understand that this may be workflow specific but I still think that in case all elements share one level and the attributes are set ByLevel the DWG save process could do better. Not sure how the comparison is done between cells but it may try to ignore level when comparing or have the option that the  shared cell instance is placed on the level of the first graphical element of the original cell. This is default behavior if "Insert Layer for Normal Cells" is off so there is need to have additional option to apply this to all cells and use only cell name for comparison.

    Main reason why this is needed in DWG save is because shared cell concept in DGN workmode is unfinished/outdated and have issues. Similary as with annotation cells that idea is good but it is not well implemented and it renders them hard  to use in practice.

    Filed formal Enhancement Request 160892 for this.

  • What you have said about the option of insert layer for normal cells is correct and it just tells you the conceptual difference of the two types of cells from a different angle - because a normal cell is defined by itself it has no separate instance vs definition so there is no level for a normal cell. When you convert a normal cell to a shared cell, a level is required for the shared cell instance. By default, the level of the first child element is used as the level of the shared cell instance for DGW save as. Some users wanted to place the instances on different levels. This option is helpful for that purpose.

    I'm curious about what problems you might have using annotation cells. Would you mind to share with us some details about them? Also, somehow the link you have under "issues" did not lead me to a correct address.



Reply
  • What you have said about the option of insert layer for normal cells is correct and it just tells you the conceptual difference of the two types of cells from a different angle - because a normal cell is defined by itself it has no separate instance vs definition so there is no level for a normal cell. When you convert a normal cell to a shared cell, a level is required for the shared cell instance. By default, the level of the first child element is used as the level of the shared cell instance for DGW save as. Some users wanted to place the instances on different levels. This option is helpful for that purpose.

    I'm curious about what problems you might have using annotation cells. Would you mind to share with us some details about them? Also, somehow the link you have under "issues" did not lead me to a correct address.



Children