Skip to main content
18-Opal
July 25, 2016
Question

Drawing Symbols: Override vs Copy

  • July 25, 2016
  • 3 replies
  • 7002 views

Frustrations aside for how this module has been sorely neglected, this question is to better understand how the current state works to hopefully find a manipulable workaround.

 

When adding a symbol to a drawing sometimes it asks if you want to override an existing symbol with the same name, which would replace all shown instances with the new one from file.

Other times it just ignores the fact that there exists symbols of the same name and imports a copy with  " (1)" at the end and doesn't replace any with the same name.

 

In neither case does it actually give you a choice between the 2, nor does it indicate any reason why it behaves differently in different cases.  Does anyone know why sometimes it imports a copy, and other times it overrides the existing symbol on the drawing?


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

3 replies

23-Emerald IV
July 25, 2016

From my experience it is based on the version added to the extension.  For example, if "some_symbol.sym.1" is added to a drawing, later adding "some_symbol.sym.2" will prompt for replacement.  If you then go back and try to add "some_symbol.sym.1" back in (or even "some_symbol.sym"), it won't ask about replacement.

LawrenceS18-OpalAuthor
18-Opal
July 25, 2016

I actually tested that prior to posting, and it is still adding it as a copy instead of overriding the current symbol on a drawing.  There must be something else going on.

12-Amethyst
July 25, 2016

It will do replacement if the symbols are the same name *and* the same relative path.  Symbols were designed back in the ancient days to support having the same name symbol under different paths (<symbol dir>/path1/foo.sym and <symbol dir>/path2/foo.sym).  You can see the relative path of a sym def in the drawing with Symbol Gallery > Symbol Dir, and you can change it by saving the symbol to disk (in the current directory, if you wish to clear an unwanted path, which is the usual change you'd want to make.

It may be (I think so, but I don't know how everyone is using the software) that the concept of differentiating symbols by relative path is archaic and not wanted by most people.  We could have a setup or config option (depending on what it would need to do) to say whether a model recognizes such symbols as different or not.  If that is of interest, please make a Product Idea for it.

23-Emerald IV
July 25, 2016

FYI, all the testing I did was with the symbols in the same folder and path.  Might be nice to whip up a quick excel matrix - name, path, extension vs. replace and re-add.

1-Visitor
July 27, 2016

I;ve had recent experience merging two drawings which were both derived from a single original. Creo simply duplicated all the symbol references, so Triangle copied to triangle(2), and so on for dozens of symbols.

To be rid of the duplicates I had to manually locate them and replace the suffixed ones with the non-suffixed ones. It took a significant time because FIND won't find symbols except on the current sheet, so that added to the march.

Symbols have been a summer-intern hack forever. The best it ever got was when PTC exposed the layer scheme used to manage grouping visibilities. Much easier to change what layers geometry is than changing levels and the rest of the symbol management menu scheme. Then they hid the layers and it went back to playing wack-a-mole.

The biggest part missing from Creo is a general purpose scripting language that would allow geometry creation commands to be embedded into objects, such as symbols, rather than making external software such as Toolkit, JLink, Weblink, the (truly awful C interface**,) or any of the other disjoint mechanism.

**The C interface is my favorite. Just passes all the dimensions in order of creation. No clue on the C side what those dimensions are, just an array of numbers, no names. Make an edit to a model and the C program needs to have it's arguments re-examined.

LawrenceS18-OpalAuthor
18-Opal
July 27, 2016

I think we should start a "Document" to list what we would like to see in functionality improvements for Symbols.  I wonder if the symbol UI improvements have been LOW on the priority list because PTC doesn't think many people use them very much.

While it is true that I don't think anyone LIKES using them, and many may even try to avoid using them, because of the awful UI and problems such as the one pointed out in this thread of not being able to update symbols without a headache and confusion.

LawrenceS18-OpalAuthor
18-Opal
July 27, 2016