Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X
Creo
Solved! Go to Solution.
For reference, the use cases we have been given by customers include using a drawing program to show one or another flavor of 'Detail A', and also having a multi-sheet drawing with one sheet for each instance of a family table of parts, each of which can have its own Detail A. (Maybe others? It was a numbe rof years ago...) Whether or not this is reasonable is a question for debate. However, PM has agreed that it should be considered non-standard, and so I have been authorized to improve matters, as follows:
In Creo 2 M250, Creo 3 M130, and Creo 4 M010, there will be a new config option 'allow_duplicate_view_names yes/NO'. When set to yes, no change from previous builds. When set to no, we will reject attempts to rename a view to duplicate another, and also will check on retrieval and regen draft for current duplication and give a warning. All messages will note the sheet number of the duplicate view and mention the config option by name.
Thank you for raising this issue, and enjoy the new functionality!
Hi,
please attach picture and/or upload problematic Creo data.
MH
Link to Case: https://www.ptc.com/appserver/cs/view/case.jsp?n=13415860
Case Reference: [[ref:_00DA0YLPa._5002A137Oou:ref]]
Hi,
the problem can be reproduced using Edit Value command in Creo 2.0. In Creo 3.0 and Creo 4.0 the problem cannot be reproduced, because Edit Value command is not available anymore.
Creo 2.0 development will be finished soon (in the middle of 2017). Therefore you cannot expect that PTC implements changes concerning Edit Value command.
MH
As per the Case, we have valid customer workflows that require we support same-name views, and this should be a Product Idea. However, it is entirely reasonable that this behavior could be configurable by the user:
1) Allow view names as today
2) Disallow any duplicate view names
3) Disallow duplicate views for the same top model, allow them across different top models.
It's not a lot of work, but we tend to want to gauge interest before making new config options, lest we make functionality only used by an individual customer. So if you are interested, please post it in the product ideas section, and see if people vote it up.
Can you share that use case?
Yes
Invisible to me - not on maint. Also I was refering to -allowing- duplicate view names, which I don't see as a valid case.
I agree that it shouldn't be "standard" to allow the same view name more than once, an option to allow that with the default being not allowed would be the best way.
It doesn't allow me to look at the case. I don't think you can look at other companies support tickets.
For reference, the use cases we have been given by customers include using a drawing program to show one or another flavor of 'Detail A', and also having a multi-sheet drawing with one sheet for each instance of a family table of parts, each of which can have its own Detail A. (Maybe others? It was a numbe rof years ago...) Whether or not this is reasonable is a question for debate. However, PM has agreed that it should be considered non-standard, and so I have been authorized to improve matters, as follows:
In Creo 2 M250, Creo 3 M130, and Creo 4 M010, there will be a new config option 'allow_duplicate_view_names yes/NO'. When set to yes, no change from previous builds. When set to no, we will reject attempts to rename a view to duplicate another, and also will check on retrieval and regen draft for current duplication and give a warning. All messages will note the sheet number of the duplicate view and mention the config option by name.
Thank you for raising this issue, and enjoy the new functionality!
I like the inclusion of better diagnostics, particularly if it mentions the applicable config option.
A generalization of this would be interesting - to allow the addition of a notation in the trail file of commands that have used config settings to control their behavior. There are a ton of cases where understanding why an operation is working or not working hinges on the selection of an execution path based on config options.