PARCscript Interaction with Comma as Decimal Separator

PARCscript interaction with comma as decimal separator:

The calculation scripts that are being run from PARCscript will always have to be ran with a period for the decimal separator due to the PARCscript engine requirements. It is not region aware. PARCview will try to handle these inputs from the user by converting a comma used as a decimal separator in a formula to a period whenever a tag is run, saved, or trended from the PARCscript GUI.

Therefore, the user should use either a comma or a period as the Decimal Separator. Having that said, users Should NOT use Parameter separators. Here are a few examples of good and bad inputs:

Period as a number Separator:

22.55 --- Good ----> Will be translated to 22.55 when the 'Run' button is clicked..

Comma as a number Separator:

22,55 ---- Good ----> Will be translated to 22.55 when the 'Run' button is clicked.

Comma as a Parameter Separator and Period as a Decimal Separator:

22,550.50 --- Bad ----> Should not use both comma and period in the same number.

Period as a Parameter Separator and Comma as a Decimal Separator:

22.550,50 --- Bad ---> Should not use both command period in the same number

How can the user know if the argument format is valid or not?

Users can ensure that the format of their input is correct by looking at the Generated UTag on top. If there is an argument value in the argument table, but the Generated UTag is showing a '0', there the input should be correct. Here is an example.

In this example, both a Comma (as Parameter Separator) and a Period (as Decimal Separator) have been used. As we can in the Generated UTag, the first Argument is not getting translated Correctly. However, I remove the Parameter Separator (regardless of it being a Comma or a Period), the Argument will get translated correctly as seen in the second screenshot below.

Screenshot 2

Screenshot 3 - using a Comma as the Decimal Separator.

This should be communicated to users using a comma as the decimal separator because any CALC tags that are run, trended, or saved and then re-opened for editing will have the comma replaced with a period which can be confusing without knowing the reasoning behind the changes. The user can input another value using the comma as the decimal separator but the saved calculation will use a period.