Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
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?
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.
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.
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.
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.
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:
Case2:
Case2:
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?
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.
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.
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.
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?
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.
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.
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.
Drawing Symbol Interface (UI) Improvement functionality list for PTC
And make sure to vote here: