# Weird Custom Property Behavior **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [February 27, 2026, 2:45pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229 "2026-02-27T14:45:02Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\ **Post date:** [February 27, 2026, 2:45pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/1 "2026-02-27T14:45:02Z")
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** > > ```json > 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: > > ```python > 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) > > ```python > 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? ---
**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\ **Post date:** [February 27, 2026, 2:51pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/2 "2026-02-27T14:51:26Z")
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? ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [February 27, 2026, 5:04pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/3 "2026-02-27T17:04:14Z")
It's a known issue with the object wrapper on perspective properties. > [@\[IGN-1660\] ObjectWrapper modification](https://forum.inductiveautomation.com/t/bug-15347-objectwrapper-modification/29692): > > 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](https://forum.inductiveautomation.com/t/cannot-use-update-to-change-key-value-pairs-in-objectwrapper-type/67063): > > 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](https://forum.inductiveautomation.com/t/bug-15347-objectwrapper-modification/29692) 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](https://forum.inductiveautomation.com/t/function-to-convert-json-string-or-python-dict-into-objectwrapper/32861/16): > > 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. ---
**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\ **Post date:** [February 27, 2026, 5:41pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/4 "2026-02-27T17:41:07Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [February 27, 2026, 9:18pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/5 "2026-02-27T21:18:23Z")
I made an `unQualify()` function in my integration toolkit to collapse all of the variations. ---
**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\ **Post date:** [March 2, 2026, 2:35pm UTC](https://forum.inductiveautomation.com/t/weird-custom-property-behavior/114229/6 "2026-03-02T14:35:24Z")
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.