Bug #4049
openImport actor that already exists appends strange numbering scheme
0%
Description
When I import an actor that already exists, saying Yes to use the next available id, the new actor appends a numbering scheme to the name that I don't understand. After three consecutive imports of the same DataTurbine actor, my tree now contains:
DataTurbine
DataTurbine_2_
DataTurbine_2__3_
DataTurbine_2__3__4_
I'm assuming that's wrong and should just be one incrementing number.
Related issues
Updated by Christopher Brooks over 15 years ago
I'm not sure how to reproduce this.
Doing Tools -> Instantiate Component over and over again creates
Ramp
Ramp2
Ramp3
I must be missing something?
Updated by Derik Barseghian over 15 years ago
I should've been more clear, this is using the Kepler File => Import Archive (KAR) menu item and then looking at the resulting updated library tree, not Instantiate Components.
Updated by Derik Barseghian over 15 years ago
I've checked in a fix, but am leaving this open and changing to a feature request -- see if there's a better way to go about this. When a user instantiates multiple copies of the same actor, kepler increments the number on the name of the actor on the canvas. Things can get confusing when looking back and forth between the canvas and actor tree.
Updated by Derik Barseghian over 15 years ago
Soong notes that when dragging an actor with name ending in a digit(s) to canvas, the digits are dropped.
Updated by Derik Barseghian over 15 years ago
Re: comment#4, for example, if an actor RExpressionRain2001 is created and saved in the library, when dragged to canvas, it becomes RExpressionRain. One reason is that NamedObj's uniqueName method strips the numeric suffix. I've made a change to NamedObj locally to not do this, to instead optionally append an underscore followed by a unique number. If it's the first instance, it will be RExpressionRain2001. The second would be RExpressionRain2001_2. However, the first instance still gets its numeric suffix (2001) stripped by the time the actor hits the canvas, because MoMLParser's attribute calls CompositeEntity's uniqueName().
I see 5 declarations of uniqueName(), and many calls to them. I'm a little reluctant to make changes, it seems like there could be many ramifications...
One slightly hackish solution is to have the first instance of e.g. RExpressionRain2001 dragged to canvas be called RExpressionRain2001_. This seems to work, but isn't very satisfying.
Updated by Christopher Brooks about 12 years ago
Updated by Daniel Crawl over 11 years ago
To prevent the ending digits from being removed when dropping an actor on the canvas, set the display name and make the display name and name different.