I find it amusing and weird that Designer uses CRLF endings when editing expressions, but just LF endings when editing scripts.
For example, here's a snippet from a view.json. Note the use of \r\n
in the expression and just \n
in the script:
"custom.settings_changing": {
"binding": {
"config": {
"expression": "{view.custom.Condition.changed}||\r\n{view.custom.Enabled.changed}"
},
"type": "expr"
},
"onChange": {
"enabled": null,
"script": "\tif currentValue.value \u003d\u003d False:\n\t\tsystem.perspective.sendMessage(\"validate-row\", {}, \"view\")"
},
},
Is there some reason why this happens?
2 Likes
My educated guess is that the difference is due to the underlying difference in code editors. Expressions use an older editor from Jidesoft, while scripts use a newer editor, RSyntaxTextArea. At some point I want to migrate expressions to use the newer editor, which will probably naturally fix this. I wonder if expressions serialize with \n
on non-Windows platforms...
Either way, it's clearly not something we've noticed as causing any problems, so
Due to my method of bulk editing views via JSON-to-YAML-to-JSON conversions, I've also discovered that Ignition has no issue with the expressions using LF endings. But the CRLF do come back if you edit them in Designer again.
Oh, and I am using Linux for Designer and my gateway so ... CRLF for everyone?
1 Like
Is it possible the editor widget detects which line-ending type is currently in the text blob and uses that for new edits, but defaults to your system standard if none are found?
I just tried editing an expression which previously had had no line endings and it used LF from my workstation, but then I edited one which already had CRLF and it added CRLF.
My colleagues use Windows for Designer and it's possible we may be running a mix of CRLF and LF.
(I was wrong earlier when I said the CRLF come back immediately when you edit it ... it's more complicated than that ...)