Hello folks,
This is not a game-breaking issue, since everything works correctly (so far), but I really don’t like that little red triangle popping up above my properties. I’d also like to make sure I didn’t do something wrong…
So here goes:
This is created by a python script, it’s a dict that has integers as keys.
The version is 8.1.3
If I change the key to not be an integer anymore, the problem disappears:
Note that if I only cast to a string, without adding something, the issue remains.
Could someone explain why, or confirm that it is indeed a bug ?
Thanks in advance, you guys have a great day !
Numeric keys are painful to access from other contexts, i.e. scripting. If there’s a strictly ordered list of “keys”, is there any reason to not just make this into an array?
Well, those keys are actually an ID. Here, they’re all nice and ordered, but it might not always be the case.
Also, this ID is 1-indexed, which messes things up in an array.
I’ll try making an array with a dummy 0, and maybe figure out something if the case of non-ordinal IDs presents itself.
Still, why does it say invalid key ? Is it to deter people from using numeric keys ?
Numeric keys are not valid JSON. You could make them strings instead though, e.g. "1", "2", "3", etc…
I tried that, but got the same issue.
I suspect some intermediate layer is ‘detecting’ them as numeric and coercing them, but can you show your script to coerce the keys to strings anyways?
This is not the original script, which I changed to use an array, but here’s what’s relevant:
Maybe you can use a different shape for your data:
[
{
"id": 1,
"tcu": "[]ZONE2/TCU/TCU4_3"
},
{
"id": 2,
"tcu": "[]ZONE2/TCU/TCU4_5"
}
]
I thought of this, but it kinds of defeats the purpose of what I’m trying to do, which is accessing those by indexing on the ID. This is meant to serve as a map.
Hmm. Well I’m not sure if there’s coercion going on like @PGriffith mentioned or if the system is trying to save you from constructing a JSON path that is difficult to use.
Even if your keys were "1" instead of 1 instead of a normal reference like foo.1.baz you’d have to use a more awkward syntax like foo["1"].baz. Not sure what’s going on though, maybe Paul will figure it out 
I think it’s mostly just the json tree being overzealous with the warning, actually. From what I can tell, the type is preserved as a string pretty well throughout. If you don’t care about the warnings in the editor, it’s probably reasonably safe to ignore…although I would still consider if there’s a different way to do things.
For instance, I set up a simple transform to return a dictionary with numeric strings as keys, and tested the type:
But you still get the warnings… Why would I convert to strings if it doesn’t get rid of the warnings and if it’s functionally the same ?
Things is, in this particular case, I could make it an array, make a dummy 0, and handle cases where the keys aren’t as neatly and linearly ordered. But I do have another case with the same problem, but In a more complex structure - which is why I presented this simpler case - that cannot be made into an array, and in which keys still need to be numeric values - it’s a dict of dicts of lists, which I could make a list of dicts of lists, but I still need that inner dict to keep its numeric keys…
Well, I guess I’ll just ignore those few warnings and see where that gets me. If problems arise, then I’ll try to figure something…
Thanks for your help folks
Sorry to resurrect an older topic, but this thread was almost exactly my issue, and I still have a few questions.
I’m on Ignition 8.1.7 and am getting lots of “Invalid Key” warnings in Designer. Thanks to this thread, I’ve narrowed it down to object keys that have spaces in them or start with numerals (0-9). In my case, they are the column names for the data of a Perspective table, so I have hundreds of warnings (e.g. 10 columns by 40 rows = 400 warnings).
One complaint I have is that Designer doesn’t seem to be highlighting which keys are causing the warning for me (most of the time). After working in Designer for 30+ minutes it randomly popped up the highlighting of bad keys once for me, and then I came back and noticed that they were also highlighted in the screenshots of this thread. But then my highlighting disappeared and hasn’t come back since.
My bigger question: will using with these invalid keys in a Perspective data table actually cause any issues other than the warning? I need the spaces and numerals in the column names since that’s how they need to be displayed, and the idea of dynamically building a columns property just to map from “valid” key names to column names seems excessive. Everything seems to be working right now other than the warning.
welh using spaces and numbers makes it harder to use this.props.data.data field but you can still do this.props.data['data field']
i dont think there actually is any other real problem with it tho i guess. apart from cluttering the logs and maybe a slight reduce in performance in the designer because of it xd
I don’t know if that can apply to your situation, but I ended up ditching that system and using a list of objects of this sort:
[
{
'name': x,
'id': x,
'data', x
},
{
'name': y,
'id': y,
'data', y
},
etc
]
This requires an additional (simple) step in the processing, but at least it complies with json rules and got rid of the warnings.
Another solution would be to prefix your ids with a string. Doesn’t help with spaces though, but i’d stick that in a name property or something that you access with an id or something.
It’s less convenient but it’s probably ‘cleaner’
My data is being used only for output in the table view. I don't actually need to reference it any other way, so the awkward keying doesn't affect me.
I can't alter the basic structure since I have to match the expectations of the Perspective table component. I did consider "mangling" the names in the data table, but I need them to display properly, so that would require I generate a dynamic columns property to map names for the user display.
You can, you just need to process the data in the binding on your table.
return [data['name'] for data in value.values()]
in a script transform for example.
Oh, I know how to do the conversion you mentioned, my problem is that the data is being fed into the Perspective table component and that component doesn't look for column names under the name key of the cells.
Yes, that’s why you process your data to format it in a way the table component understands.
Except, instead of formatting it where you data is stored, you format it in a transform in your binding on your table’s data property. So it’s not a name key anymore.
An alternative solution could be to store your data as a dataset directly, so that your table could use it. You shouldn’t have key issues with a dataset.
The issue is that these names are the strings that I want the table to display as the column headers (numerals and spaces and all). And they HAVE to be used as keys in the data object unless I want to use safely-mangled key names in the data table and then generate a dynamic columns table property to map them all back to the headers I want to show. I'm quite sure at this point that the dynamic columns is the only way to do this without Designer warnings, but it all seems to be working even with the designer warnings. My big question wasn't "how do I avoid these warnings" it was "is something going to break if I ignore these warnings".
This whole thing used to be a dataset and worked beautifully. I converted away since I wanted per-cell styling and coloring. 
