Weird Custom Property Behavior

[Xander_Dawson-Fink]

I’ve got an issue that I can’t wrap my head around on 8.1.37

I’ve got a custom property on my view that is an object that contains a list of objects:

Object Structure

view.custom.data = {
  "Value1": "",
  "Value2": 0,
  "Value3": 0,
  "ListOfObjects": [
    {
      "item": 2,
      "count": 1,
      "row": 0
    },{
      "item": 13,
      "count": 6,
      "row": 1
    },{
      "item": null,
      "count": 0,
      "row": 2
    }
  ]
}

I’ve got a dropdown view that sits in a table column with view render type. It sends a message to the page when it changes to update the item of the selected object in the list of objects by handing the ‘row’ and ‘value’ as an int or a long (I’ve tried both). I’ve tried a couple variations of the logic:

Message Script On Table

Original:

self.view.custom.object.listOfObjects[payload['row']].update({'item':payload['value']

Alternative 1

(On the premise that maybe the update function directly on the child of the list was problematic)

temp = self.view.custom.object.listOfObjects 
# I've also tried casting parts to a list
temp[payload['row']].update({'item':payload['value']})
self.view.custom.object.listOfObjects = temp

Instead of changing the array, though, I get a new custom property object.listOfObjects[0] (which the designer doesn’t like as a key name of course) with the value {'item':intValue}.

Is there something that I’m doing wrong to update a single key in an object contained in a list?

[Xander_Dawson-Fink]

Ok, I just realized that if I just assign it like self.view.custom.object.listOfObjects[int(payload['row'])]['item'] = payload['value'] it works perfectly fine. Not sure why the update function is weird, even if I cast everything to “normal” python types, but problem fixed I guess?

[ryan.white]

It's a known issue with the object wrapper on perspective properties.

[IGN-1660] ObjectWrapper modification

Dears, I am currently using the 8.0.5 release. After the upgrade from the 8.0.4, I noticed a change in the manipulation of an ObjectWrapper instance. For example: the code below explains what I found: the param parameter is an ObjectWrapper # Configure additional properties param.Username = userName param.Timestamp = fer.util.date.dateToSqlString(fer.util.date.getTimestampUtc()) I try to set the Username and Timestamp properties, but they did not change. The above code run inside a libra…

Cannot use .update() to change key value pairs in ObjectWrapper type

Ignition Version 8.1.17 I have a Tree component in perspective that I'm using to allow users to modify what items are available in dropdowns in another interface. Each item in the tree has an 'ItemData' dictionary in the 'data' key of the item. I'm able to add to the tree item's 'items' key utilizing .append(), however I am unable to modify the dictionary that is present in the item's 'data' key using .update(). Searching the forums yielded this post, but it appears they were trying to modify…

I normally use a modified version of the sanitize function from this post whenever I'm interacting with a dict or list property in a script:

Function to convert json string or python dict into ObjectWrapper

Forcing each to the expected type while traversing makes a deep copy: def sanitize_tree(element): if hasattr(element, '__iter__'): if hasattr(element, 'keys'): return dict((k, sanitize_tree(element[k])) for k in element.keys()) else: return list(sanitize_tree(x) for x in element) return element EDIT: Got rid of the unnecessary zip() and used only one keys() iterator instead of two.

[Xander_Dawson-Fink]

Oh, ok. I had poked around for several hours trying to find something about it. I didn’t include the term object wrapper since when I find solutions to problems here, they don’t tend to have the right namings, so I usually just describe the end result that’s unwanted. Thank you for attaching those links, though.

[pturmel]

I made an unQualify() function in my integration toolkit to collapse all of the variations.

[Xander_Dawson-Fink]

Man, of course you did. It sounds like your toolkit has everything one would need to solve all the little issues (quirks?) with Ignition. I hope I eventually get to work on it in a professional environment and not just my home bench.