Incorrect indirect tag values and qualities

We have a problem with a lot of our forms that we just noticed regarding indirect tags.

We are running FPMI 3.3.1 (due to deployment problems we encountered when upgraded to latest version which might be related to signature on reporting plugin) and also did some testing with Ignition 7.0.8 to see if it happens there as well (which it does).

First some background, we have many devices that are identical in nature and share many tags so we use indirect tags to alter the front part of the path to switch between the different devices.

We add dynamic properties to the root container (or at least a container) that holds the current selection and the combobox will update that dynamic property. All control properties are mapped using standard indirect tag binding.

On the Open event script of the window it will validate if the currently saved dynamic property is really in the database and if not default it to a different value that is present. (This is currently mostly because my test system has a different device list than production.) I think the activate window script will also do this validation. Don’t think these scripts are affecting behavior but we see the problem when this script fixes the incorrect devices.

Also we might open these forms from a button on another form which has the device already select. We then open the new window and change the dynamic property to the correct device as part of the action script that opens the window.

So the problem is that some times the tag values are not correct tags. So they are actually showing the values from a different device. Presumably either the values from when the form was saved or the values associated with the dynamic property as it was saved. Normally the problem only occurs when the form is first loaded but can happen if its unloaded from form cache if its not already open. It also an happen if we allow the user to switch from one user account to another. The problem never happens if the form is already open or if its still in the cache.

Some of the windows have say 100+ tags mapped this way and only about 10-15% of the the tags are noticably incorrect. I would say that its not just quantity of tags on the form though as it happens on some of the smaller forms. Usually it is the quality that is incorrect but sometimes it is the value as well. When testing with ignition we see usually only the status incorrect but same problem still is present.

As an aside, the presence of debug print statements will sometimes alter behavior.

A button might have code similar to the following which changes the dynamic properties to set the opened window to the appropriate device.

window = fpmi.nav.openWindow(event.source.LinkedWindow) window.getRootContainer().DataSource = event.source.parent.DataSource window.getRootContainer().System = event.source.parent.System
A control value might be bound like the following where TagName is a dynamic property on the control. Sometimes datasource and system are combined to a third dynamic property to reduce indirections.

{0}{1}{2} 0 = Root Container.DataSource 1 = Root Container.System 2 = Root Container.Control.TagName

The values usually correct themselves as soon as a new value arrives for the tag (which in our system can be many minutes if the value is not changing). or if the configchanged field is set. Both of these are server side fixes and affect everyone connected but the problem is only with the client so I would prefer not to do anything drastic like “update sqlt_core set configchange = now();” every time a window is opened on a client.

So the initial questions are:

  1. Is this a known problem? If so, are there workarounds or better approaches?
  2. Is it possible to cause a control to completely update itself after it thinks its done binding?

This is definitely not a known issue.

I think this might simply be a case of timing where your initialization script in the window’s internalFrameActivated is fighting the button’s initialization logic.

  1. You shouldn’t be initializing the variables on the window’s root container like that. This is what parameter passing is for.

  2. Bind a label on one of these screens to display the indirection parameters. This way you can tell for sure what they ended up as after the window was opened - that might help flush out the reason they’re being set incorrectly.

  3. Can you call us and demonstrate this over GoToMeeting if #1 and #2 don’t make it apparent what is going on?

Ok I think the parameter passing option was overlooked here. I thought it was basically doing the same thing but obviously there are some timing issues.

I suspect #1 will help in the posted case of the button launching the form. I dont think it will help the case where we are correcting the initial values because they are invalid on first load. There I think I can do some tricks in the menu handlers to use the parameter passing I think.

We actually created another container under the root container to hold the dynamic properties so that the top container was easily accessible using the mouse. The fact that you have to select Root Container in Project Browser and then Component menu to access those dynamic properties was not obvious when the forms were first developed so its really window.getComponentForPath(‘Root Container.ContainerALL’).Property in practice. This is the first time that has really become a problem.

I would like to get rid of this secondary container now to be able to test this better but that is difficult with the large number of indirect bindings we have. This will take some time to restructure.

I did some testing with invokeLater and it worked reasonably well but it feels too much like a kludge. I’ll post back after redoing the dynamic properties on the forms.

After rebinding the indirect tags and removing the intermediate container it seems to be working as expected. Actually the intermediate container may have caused the bulk of the problems as even the original code I posted was working as I would expect at least from the button case once it was removed and all of the properties were on the Root Container object.

I’m still encountering problems with the case where the value is changed as part of the Open event because the saved default was not valid.

For that I will just try to find a way to initialize the relevant properties from a global variable that is initialized from our database the first time it is accessed.