# Bug - Property Bindings Not Initializing when the path has a component with a meta.name binding in it **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [November 21, 2022, 5:23pm UTC](https://forum.inductiveautomation.com/t/bug-property-bindings-not-initializing-when-the-path-has-a-component-with-a-meta-name-binding-in-it/66761 "2022-11-21T17:23:48Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Sam\_Engsberg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sam_engsberg/32/37540_2.png) [@Sam\_Engsberg](https://forum.inductiveautomation.com/u/Sam_Engsberg)\ **Post date:** [November 21, 2022, 5:23pm UTC](https://forum.inductiveautomation.com/t/bug-property-bindings-not-initializing-when-the-path-has-a-component-with-a-meta-name-binding-in-it/66761/1 "2022-11-21T17:23:48Z")
Was on the verge of going to support and I happened to find my issue. Perspective does not like it when you reference a property path that has bindings attached to it. I found the bug was due to a time-saving measure I tried when copying lots of flex containers for a checkmark and color marker combo I wanted to link to my power chart. I wanted to have a custom property with the UDT instance name as well as have the container's name (meta.name) be called that. My solution was to link the container.meta.name property to my custom.displayName. It's a silly time-save in retrospect. In my power chart, I went and set my 'enable' property to my checkmarks state (ex. ../FlexContainer/T1/Levels/ **T110-LET** /Checkbox.props.selected, where **T110-LET** is my UDT name linked to that custom.displayName property I mentioned earlier.). It worked great in designer preview mode, but once I opened a session or rebooted designer, nothing worked at all. Manually going to the binding page in designer and pressing enter re-bound the binding, but it didn't last between sessions. I think because the tag path was not 'fixed' and since that T110-LET tag path didn't exist until the custom.displayName was read, the property binding to that spot didn't resolve and gave me a null. After troubleshooting, I found when I got rid of my meta.name custom property binding, the issue cleared up. The solution was not using any bindings for my meta.name properties on my components. A tad more work, but that's a separate issue. ![flex container dynamic meta-name](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/a/8add1d44adab7c9cb32064308b9041b2fa22436f.png) ![power chart pen bindings](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/5/f5cab4a2a6eaca96741b09adf43cba41122f8724.png) ---
**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:** [November 21, 2022, 5:29pm UTC](https://forum.inductiveautomation.com/t/bug-property-bindings-not-initializing-when-the-path-has-a-component-with-a-meta-name-binding-in-it/66761/2 "2022-11-21T17:29:21Z")
A component's name is so fundamental to the operation of both Perspective and Vision that I don't understand why these are allowed to be bound. There are numerous historical cases of name bindings disturbing operations. Particularly since some kinds of bindings report a dummy value on startup before the real value arrives, and names have restrictions that are likely broken by a dummy value. Just don't. ---
**Author:** ![Sam\_Engsberg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sam_engsberg/32/37540_2.png) [@Sam\_Engsberg](https://forum.inductiveautomation.com/u/Sam_Engsberg)\ **Post date:** [November 21, 2022, 5:52pm UTC](https://forum.inductiveautomation.com/t/bug-property-bindings-not-initializing-when-the-path-has-a-component-with-a-meta-name-binding-in-it/66761/3 "2022-11-21T17:52:48Z")
Definitely a learning moment of something I really don't want to mess around with. Just inviting issues and for things to break.