CustomProperties of Root Container not pushed to clients

Ignition
1

I’m not sure if this behaviour is new, but in V7.5.6 changed values of CustomProperties in a windows Root Container are not pushed to running clients. I have to restart the client for the changes to become visible.
All other CustomProperties are pushed, so if i move the properties to a Container inside the window everything works as expected.

2

I bet the problem is with the cache and not the version of Ignition. Do the following:

  1. Close all clients and designers on the client machine
  2. Delete the .ignition folder inside of C:\Users\username (replace username with your logged in username)
  3. Launch the client again

It should be back to normal after that. If not and you easily replicate the issue call let us know.

3

I just checked on another machine with a test system, and this is reproducable.

I attached an window export. There are two custom properties, one in the Root Container, another in an Container Component.

  • Launch a client
  • Window displays the current values of both properties
  • Change both properties in the designer and save the project
  • The property of the inner container is updated in the clients, the property of the Root Container is not

To update the property, the client has to be restartet or the user has to log off and log in again.

I came across this problem with two clients that are used as displays in the production area and are never restartet. Those clients did not reflect the changes i did.
Test_Window_2013-04-10_1843.proj (6.12 KB)

4

Ok, I know you’re going to hate to hear this: but this is a feature, not a bug! Let me explain:

The Vision module’s window system is made in such a way that root container properties are special. These properties are used as the parameters for that window.

You can create a generic window, for the sake of example, let’s say it’s a pump control window. You would then put the pump ID as a root container property for that window. All around your project, you’d then open up that window, passing it a different pump ID each time you opened it. In this way, the generic window can be re-used by altering the root container properties (the parameters).

When you do a hot-update, it is actually downloading the changes to the project, closing all of the open windows, and then re-opening them in the same locations that they were at. As you’ve discovered, it also remembers the values of any root container properties, and re-sets those on the new instances of the window.

It should be obvious given the example above why this is important. If you had your pump control window open for pump “82”, did a hot-update and we didn’t preserve the values of the root container properties, your pump control window would open up in whatever state it had been left it most recently in the designer.

Not that you understand how this works, you should be able to work around it quite easily. If something is not meant to be a window parameter - don’t store in on a root container property. All other properties will get their values from the designer (or any applicable bindings)

Hope this makes sense,

5

Note that this means every parameter must be passed to system.nav.openWindow() every time (unless for some reason you want them to persist). If you add a new property to a window you have to be sure to add it to every single place that window is used without fail.

I would strongly recommend creating an app function to abstract this for any window used in more than one place. This would also allow the use of optional arguments:

# In app.nav:
def pump(id, mode='view'):
    import system
    system.nav.openWindow("Pump", {
        'id': id,
        'mode': mode,
    })

Now any of the following will work, and will continue to work even if additional optional arguments are added:

app.nav.pump(1)
app.nav.pump(2, 'edit')
6

Sure, that’s a good idea.