Dot syntax failing with tracked-variable labels

[guiroehe]

[ FlexSim 25.1.1 ]

Hello,

from examples and answers from the forum (e.g. https://answers.flexsim.com/questions/80701/graph-multiple-data-of-a-tracked-variable-in-one-c.html, https://answers.flexsim.com/questions/177837/performance-measure-from-tracked-variable.html) the following syntax should work to update tracked-variable labels:

myObject.myLabel = newValue;

or

myObject.myLabel.as(TrackedVariable).value = newValue;

However, as one can see below, the only working syntax is using the "labels" format:

myObject.labels["myLabel"].as(TrackedVariable).value = newValue;

It also fails when reading the variable content:

[moehlmann_fe · Accepted solution]

Both examples you linked use Tracked Variables from the toolbox and the references point to the node in both cases, making it possible to cast the reference as TR and read the property.

Using object.labelName gets the value of the TR-node, a number, which can not be cast as a TR. You do in fact have to use the object.labels["labelName"] syntax to get the TR/Label-node and access properties of the TR.

[guiroehe]

Hi, @Felix Möhlmann , thank you.

You are correct on your interpretation. My observation is about the incorrect syntax used in the previous answers from FlexSim. I could not find any explicit reference about this in the help files.

Thank you for the confirmation.

[Matthew_Gillespie]

@guiroehe Those two examples you referenced are not "incorrect syntax", they both work. For example, 

reference.as(TrackedVariable).maximum

This works because reference returns a node and the node can be cast as a TrackedVariable.

What's different about your situation is that you're using the dynamic label property "statsItemLifetime". This doesn't return a node. It returns the value of the "statsItemLifetime" label node. To get the actual node of the label node you have to use the object.labels["labelName"] syntax.

[guiroehe · Accepted solution]

Hello, @Matthew_Gillespie ,

I understand, despite the very confusing and sparse documentation and attempts to make sense of this.

As a suggestion, FlexSim should get fix this "auto-return value" for labels to a proper object-oriented architecture:

just return whatever object the label is.

Currently:
- it does not work well if a label is anything but a number or a string

- it causes problems when one stores macros on labels

- is causes problem when a label is an object of any type

My suggestion would also eliminate the need of extensively annoying casting, which is actually a counter example of C foundation (or any other decent OO language coming from C).

[Matthew_Gillespie]

Labels are working as designed. They do a great job doing their primary purpose which is quickly storing and retrieving little bits of data on an object. We will not be "fixing" this "auto-return value" because that would totally destroy their purpose. 

"it does not work well if a label is anything but a number or a string"

Labels work great for setting and retrieving numbers, strings, and direct pointers to objects. It's also very easy to automatically evaluate FlexScript labels. These are the main things that your average user uses labels for. That's why we provide this quick and easy way to get and set simple values on labels. 

If you are doing something more complicated with your labels you need to use the labels["labelName"] syntax to make sure you get the actual label node.

The documentation is pretty clear on how to use labels, in my opinion. 

FlexScript labelProperties 

FlexScript labels

Feel free to create a separate suggestion post with any ideas you have for how this could work better for you and see if other users agree.

[guiroehe]

@Matthew_Gillespie,
I understand your point, despite my personal opinion is different.
Considering FlexSim is trying to move to a ".dot syntax" and labels seem to have a huge part on it (e.g. labels storing flexscript as a surrogate to object methods), ambiguities arise when one has to decide between using object.label (= object.labels["label"].value) and object.labels["label"].evaluate(), for instance. The same applies for labels storing macros or other "more complicated" (?!) things.
Instead, if a label always returns its node, one can easily decide between adding ".value", ".evaluate()", doing a cast or any other method to the node. This would make overall code writing simpler, potentially eliminating the need for the ".labels[label]" syntax.

As I said, its my opinion. My intention was not to antagonize you, just highlight how this can be confusing to "your average user". Regarding the documentation links:

- a reference about how labels work as tracked variables is missing there

And on the tracked-variables:

- a reference about how tracked variables need to be updated depending on their type (cummulative, level, time-series, ...) would be appreciated, as they will often be used as labels, despite this is a different subject.

Thank you.