Drawing Symbols: Override vs Copy

[LawrenceS]

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.

[TomU]

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.

[LawrenceS]

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.

[mender]

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.

[TomU]

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.

[LawrenceS]

Thanks for the explanation Matthew Ender‌.  Previously I only changed that directory in order to save symbol in a directory other than the default.  But it sounds like that somehow sets it for the entire directory.

The first time I tried what you described it seemed to work, however when I tried to reproduce it I have not succeeded.  I am not sure what I am doing wrong now.  These are 3 cases of tweaking how I add the file.

Case 1:

1. Open Drawing
2. Set Symbol Directory to "Submit" folder (Creo confirmation msg received: "The root directory for user-defined symbols is now...\submit")
3. Write: Pick Instance: select symbol ISO, Leave blank and Select checkmark to confirm directory location as ...\submit.  Done.
4. Custom symbol: Browse and select symbol ISO.  Comes in and doesn't ask to replace but is not a copy.

Case2:

1. Copy previously saved symbol from different user on different machine and put in same folder as before: "...\submit" (maintaining same name and iteration e.g. test.sym.1)
2. Set same submit folder, as before
3. Custom symbol: Browse and select symbol ISO.  Comes in and doesn't ask to replace but is not a copy.
4. Checked symbol and is NOT the updated symbol but the one on the drawing.

Case2:

1. Immediately after trying Case 2, I
2. Navigated to my network location, renamed from iteration 1 to iteration 7 (e.g. test.sym.1 --> test.sym.7, which was the next in the previously used iterations).
3. Custom symbol: Browse and select symbol ISO.  This time it came in as a copy with a (2) at the end, and was the updated symbol.

It sounds to me that there is an odd combination of things going on here that is overly complicated.

Can you please provide advice on making this simpler, easier, or more predictable?

[mender]

It is also the case that symbol definitions try to use the .# version extension as an idea of version number, which is not actually reasonable except in the specific case of a symbol library that is never purged of old versions.  This is a separate issue from the 'relative directory' part.  In case of confusion due to this, we won't think they are different (and make two versions of the same symbol), but we could erroneously think one is definitely the older vs. the newer.

It also doesn't help that the factors are not immediately visible to the user.

I fear that as it stands, you have to engage in some silly gymnastics to be sure of getting the desired behavior:  1) Symbol Gallery > Write the symbol to the current directory, where no such symbol exists now, as foo.sym.1.  This sets the drawing's symbol definition's relative path to none and version to 1.  2) Copy the desired symbol to the current directory (or in the symbol directory) as foo.sym.2 (or larger number).  3) Symbol Gallery > Redefine, or Custom Symbol > Browse, and load foo.sym.2.  Foo matches foo, no relative path matches no relative path, and 2 > 1, so we'll prompt to update.

For a 'less-1989-ish' design, you'll need to ask for an enhancement to improve it, as it will be a project.  Not a very large one, but definitely requiring allocated development and testing time.

[LawrenceS]

Matthew Ender‌, thanks for the explanations and suggestion. I would very much like this problem fixed.  How would you suggest wording it so that PTC would recognize it as something they could fix sooner rather than later?

The reason I ask is PTC keeps pushing off improving the symbol module

And although the creation of complex symbols is a headache and very time consuming, the final product of the user being able to toggle through dozens of permutations (and perhaps hundreds) is really outstanding.  We just need a UI that is FAR 'less-1989-ish' 🙂  It would be nice for this specific improvement if we didn't have to wait till Creo5 or beyond.

[TomU]

Lawrence Scheeler‌, I'm not sure if you've joined the Creo 4.0 Sneak Peak group, but maybe this is worth testing in the Creo 4.0 beta.  If the behavior is still the same, you could dialog directly with the product manager(s) about the behavior. 

[LawrenceS]

I did, but did not gain permission from IT in time to do the live access.  Now IT is requesting us jump through hoops for us to install it so we are going to wait until it is on the normal PTC download location before we can test it.

From a product idea someone tested it and commented that the Symbol interface did not appear to get ANY updates and are now looking at MAYBE doing in Creo5.

Update define drawing symbol user interface

Whether or not they changed something this subtle, perhaps Matthew Ender‌ or someone else who has access to testing Creo 4 can tell us...?  Anyone up for testing this and dialoging directly with prod. manager?

[mender]

It's a question of allocation of scarce resources.  We always have a lot more useful things we could do to make the software better than we have people's time to do so.  For prioritizing this relative to other detailing work, it'd be the Product Manager.  For prioritizing detail work generally, so said PM has more resources to work with, that would be a higher-level question.

[dschenken]

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.

[LawrenceS]

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.

[LawrenceS]

Drawing Symbol Interface (UI) Improvement functionality list for PTC

And make sure to vote here: