[BUG-4446] Custom properties and bindings get disappeared even after saving the project


Hello Community,
I have shared a screenshot of the Ignition perspective view on which I am facing the problem. I have created a perspective view with the name GEN_CAT and added labels.
These are the following steps that I am trying to do with the label component:

  1. Creating a custom property with the name “Val”.
  2. Linking the custom property to the text property of the label component.
  3. Linking the “Val” custom property to a UDT definition.

Every time when I save the project and close it and then reopen the project again the bindings got disappeared along with the custom property that I have created.

“When I create a custom property in the view itself and do the bindings then the problem does not occur.”

The issue appears only when I create a custom property in the component.

What would be the reason and solution for this?

2 Likes

Are you using any VCS with this project, like git or similar? A good way to check saves is to look at the project’s local files to see after saving if the view.json file has updated to include those custom properties.

1 Like

Insure that after creating the custom property it has the “Persistent” property checked true.

3 Likes

Thanks a lot. “Persistent” property was unchecked. After enabling it, the issue got resolved.

What is the reason that a custom property disappears if you uncheck Persistent? If it gets unchecked, how do we get it back? I went into the JSON and set back to true, but it still remained invisible.

My (limited) understanding is that the component reverts back to the default props unless they are marked as persistent.

I'm not sure on this one, kind of sounds a bit like a bug.

Perhaps, @cmallonee has a good answer?

It really boils down to non-Persistent properties are not saved with the project. This is most important for bound properties, but it also applies to custom properties.

Consider a scenario where you're testing out a View in the Designer and you want to see how a Label appears when it actually has a username present. The text of this Label is bound to a custom prop "username", but that custom prop doesn't have any bindings itself - it expects something to write to it. Let's say you manually apply "cmallonee" to Label.custom.username. You don't want that value saved with the project, so you remove the Persistent flag. This results in a scenario where the property is present, and allows for you to see how the Label will look when it has a value to reference, but also prevents the accidental saving of "test" or "proofing" data.

The next time you open this View, the Label.custom.username property will be missing until whatever mechanism you have to write to the prop does so, because the username prop wasn't saved as part of the project.

To put the property back into place on a permanent basis, you'll want to resupply the property - adding it back in as you would any other property - and make sure the Persistent checkbox is selected/active before saving the View.

It's not, and the reasoning is convoluted. Buckle up..

The custom.someProp persistence setting is part of the propConfig object of the component - and is NOT a property. The propConfig object defines how properties work, but note that there are no property values here.

Consider the aforementioned scenario, where we've added some Label.custom.username property to the Label, but we turned off Persistence. Modifying the custom.username property configuration to now be persistent is only saying "when the custom.username property exists, it should be saved with the project"; but the property does NOT exist. Assuming you have modified the custom.username property configuration to once again make the property persistent, that setting won't have any effect until the exterior mechanism writes to that custom property or a user manually creates the property - at which point the existing configuration will no longer be "orphaned", and will begin applying to the property.

It's important to note that the custom.username entry in propConfig MUST be in place regardless of the presence of the username property, lest the next time you manually add the property it would ignore the persistence setting.

3 Likes

Thanks for the explanation. Here's something I'm struggling with though, if someone develops a view with a custom property that is not set for Persistent, then 6 months later someone else needs to go behind them, how would they know a custom property exists without poking around in the JSON file, since the custom property will not be visible and there is no other marker present (like that for script or event)?

1 Like

That sounds like an argument to not toggle the Persistent checkbox in the first place. We can only provide the ability to handle persistence and the reasons why it might be helpful. I personally never disable persistence because I always want to know what properties are in place. Views do have the option for documentation (right-click the View node in the Project Browser), but even listing out non-persistent properties there requires that someone knows to go and read the documentation.

As a more direct answer to this: they wouldn't. I'm sorry I don't have a better answer for you, but if you're going to hide properties from the Designer, you're going to be hiding properties from your in-house designers.

1 Like