Imagine the following scenario: you need to configure an AF attribute to show a value from another attribute located in another element, but the element may can change depending on the value of a 3rd attribute. Confused? Let me give a practical example.
An element is used to represent a wind turbine.
You want to use the wind speed value of a neighbor turbine in a calculation located at the original turbine.
Who is the neighbor turbine? The neighbor turbine name is retrieved from a AF table, but it could come from another type of DR too.
As you can see, we cannot use AF formula, because the path of my source attribute is dynamic (depends on the value of another attribute).
I was inspired by the old "String Concat" data reference, and created the "Pointer" data Reference. It basically "points" to another attribute, which path is formed by the concatenation of static strings and/or dynamic attribute values and substitution parameters.
Let's suppose the turbine WGT007 has an attribute called "Neighbor Turbine". The value of the "Neighbor Turbine" attribute is equal to WGT001, retrieved from a table. Turbine WGT008 will have a different neighbor, and so on.
WGT007 has also an attribute called "Wind Speed Neighbor", configured with the Pointer DR (config string = "..\";Neighbor Turbine;"|Wind Speed")
Behind the scenes, it will bring the value from the concatenated string separated by ";". The literals are entered in double quotes. If without double quotes, the DR will consider it an attribute, an will retrieve it's value. The Pointer data reference will concatenate everything (literals and attribute values), and it will try to retrieve the value of the attribute pointed by this dynamic path. In the example above, the resolved path is "..\WGT001|Wind Speed".