Display text string from Group Name - "..Name"+' '+".Name" becomes "..Aera1.Name"+' '+".Name" after moving object

[Tanquen]

I have a popup that gets the group names to use in a text string. This works at first but after moving the object to a new group the first Group name becomes hard coded so they all have the wrong area name in the text.Is there a way to stop it from changing the animation expression?

"..Name"+' '+".Name" becomes "...Aera1.Name"+' '+".Name"

[du5tin]

Hi, if this is a standard mimic in a regular group (ie. Not in a template) then there is not a way to keep this from happening. There are equally as many situations you may want those links to persist. I understand your pain. We moved a number of templates once on a large system and had to re-work all the relative references that looked up the tree for names and other information. 

If this is inside a template then the animation will stay fixed for all the instances when they move to different locations. I highly recommend changing your setup to a template and instance if you can. Or get to a point where this mimic does not move very often. 

[Tanquen]

These are in a template.

[geoffpatton]

One of the best features of ClearSCADA/Geo SCADA is that when you rename and move things the links to objects, tags, etc. it update them so nothing breaks.

You are using relative addressing which also great so you don't have to use the absolute path from the Root of your database for everything.

I am assuming you are using this in a animation on a mimic object, in the Expression if you uncheck "Relative" it then uses the absolute path which then will not be updated if you move the mimic location. Absolute path may not work out for you though if you using are template/instances.A absolute path in a template will be the same path/result in all the instances so the instances will all display what is in the template, not what is in their individual instances.

[du5tin]

My recommendation is to get these templates to where they need to live and do not move them so the relative references are no longer updated. Then lock down the document content of the mimics with these relative references inside the template.

Sometimes working around this means getting creative. We like to use two mimics layered on top of each other if we need "locked" content , particularly relative reference animations and custom content in the same template. Put your header, footer, and consistent graphic elements on the main mimic, keep its document content locked (Document Content not property overridden). Then layer in the custom mimic on top and property override its content. 

[BevanWeiss]

@Tanquen Those are the opposite of hard-coded... the dots infront of the reference indicate that they are 'relative', so when you move them around they will dynamically update.

This can be annoying if it's not what you want, and it is the default behaviour, even in some silly situations.

If you get rid of the "." at the front, and specify the FullName to what you want, then this is hard-coded, and no matter where you move this animated object to, that reference will remain fixed to the object that it originally referred to.

As mentioned, one of the great features of Geo SCADA is the 'auto-patching' which means that whether you use a Relative or a Non-Relative link, if you rename / move the object that is being linked to (or the object holding the animations), then the reference will (almost always) automatically update to remain pointing at the object that it was linked to.

If it has indeed only patched a part of your animation, I would consider that a bug.

You'd need to have screenshots showing the exact steps that you went through to get it to this point though.

It looks more like you moved the entire Group from {some path}.Aera1.Group, into {some path}.{Somewhere else}.Group.

So originally "..Name" was 'Aera1', and ".Name" was 'Group'.  You only moved it, so it tried to keep those references the same..

Hence, the old "..Name" should still have been 'Aera1', i.e. "..Name"->"..Aera1.Name", and ".Name" should still have been 'Group', i.e. ".Name" stays the same.

Did you drag the Group?

If you had of Copied/Pasted, or I suspect even Cut/Pasted, then it would have worked the way you wanted I believe (unsure on the Cut/Paste exactly).

[Tanquen]

It is not opposite of hard coded. It will no longer change and update to the area it is in. I put in "..Name" it changed it to "..Aera1.Name" and its now hard coded to the wrong group.Before it was moved it was not hard coded to any group. If I remove the hard coded part to the wrong group and put it back the way it was, it works again and it grabs the correct area name as it is no longer hard coded to the old one. The stuff in front of the dots is the relative part, the stuff after should not change... or so I thought.

Yes, I moved and yes if you copy it that part seems to work. It was in the wrong area so I moved it but then found that the text strings were then wrong. I did not think I would need to copy it and then delete the old one and maybe break references to it?

[geoffpatton]

In your example the only thing "hard coded" is .Name everything before .Name is relative and will update it you move the mimic to another location.

[Tanquen]

Copy yes, move no. If you move it, it takes the current group name and makes it hard coded to that group. 

If moved from Area1 to Area2:

"..Name" becomes "..Aera1.Name"

If copied from Area1 to Area2:

"..Name" stays "..Name"

[BevanWeiss]

Did you drag it, or did you Cut/Paste?

If you dragged it, then I'd say it did exactly what it should have.  It was referencing "{path}.Aera1.Name", you never told it not to be referencing that location, so it kept referencing it, and patched its references to suit.

If you had of Cut/Paste'd, then I'd argue that it did the wrong thing.  Since once you cut, it should be considered as no longer in the context it was in.

[Tanquen]

I don't know, there would have to be a pretty good use case for that and I'm not sure what that would be. I didn't hard-code it to the group name for a reason. The only scenario where it leaves it alone is when you copy it. If I drag it or cut and paste it, it takes the expression I entered and modifies and hard codes it to forever be tied to the old group. Maybe there's a good reason or scenario where you would want that but I'd rather it leave what I entered alone. You must be doing some pretty fancy stuff if you wanted to behave one way if you create it from scratch or copy it and another way if you move it after it's been created.

When you delete something it warns you that other objects are using it and if you try to create something with the same name it warns you maybe when you drag an object it should tell you it's modified the following expressions.