Finding Tags used in Bindings

I’m still trying to find a good way to determine which tags in some projects that I have are being actively used on screens in that project. I know that this is a difficult, if not impossible, task to determine with 100% accuracy. It would be nearly impossible to track down any possible location where a tag binding might be due to dynamic and indirect addressing or tag addresses present in scripting.

Still though, I was thinking I might be able to get something which is “good enough” if it just listed all of the bindings on each window component. If something showed up in this type of list I would know for sure that it’s needed somewhere. A tag not showing up in this list wouldn’t mean for sure that it’s not needed somewhere but it would help out a lot with the cross-referencing.

I don’t see where I can get a list of bindings on a window component.

On a related note, the in-window “run diagnostics” feature must already do something related to what I want since it runs through all bindings needed in that window and makes sure that they are functional. I might also be able to get the information that I want by accessing the run diagnostics feature (if this is possible).

1 Like

You won’t be able to access the actual diagnostics popup very easily/at all, but essentially all it does is recursively traverse each component under whatever you asked for, and walk through all the qualified values attached to that component (from com.inductiveautomation.factorypmi.application.components.overlay.OverlayUtility import getQualities) and see what’s good and what isn’t.

There’s also some exploration elsewhere on this forum where people walked through the actual binding objects in order to “ask” them for their tag information, but that way has a lot of potential problems. See something like this, or maybe just ask @pturmel really nicely if he’s already got something written.

Keep in mind the latter is something that’s definitely not supported by IA - if you do something wrong, you could permanently break a window and have to revert to a saved version, so make sure you’ve got backups before mucking about with internal window properties.

Hah! This stuff is too dangerous to keep too handy. I’ve broken windows and entire projects just poking around. I write from scratch on a button event when I need to do surgery. With the SDK JavaDocs at hand.

A much safer approach is to grab the window XML and search it for the tag names/fragments of interest.

1 Like

This does sound like exactly what I was looking to try. I was kind of hoping that the needed information would be available from exposed properties accessible through Python inside the project. Having to get at it from SDK functions makes this definitely not a “today” project.

Do you mean to export the .proj file containing the window and look through that (right click on window of interest and export)? All I see in there is some information about the project and a bunch of encoded junk.

SDK functions and methods are exposed to jython. Window objects have an interactionController property. No need to write a module if that is what you are thinking. You just need the SDK docs to understand what you are doing.

Add a “shift” before you right-click on a window (in the designer nav tree) and you’ll see “Copy XML to Clipboard”. That one is not encoded. Still a bit cryptic, but you will be able to see binding information in plain text.

I had already started off this exploration by calling a list of what window properties are exposed (looking for something straightforward like componentBinding or boundToTag) and did not recall seeing interactionController in that list. You’re right though, it’s there.

inputVerifier
insets
inside
interactionController
internalFrameActivated
internalFrameClosed

You just blew my mind.
What else can you do with the shift key?

<o-c m="setTagPathString" s="1;str"><str>Activator/ACMPressureSetpoint</str></o-c>

It should definitely be possible to export windows and do a text based find, regex maybe, to get a list of tag addresses bound to window elements this way. It still feels like a really dirty and inelegant way of doing something though. I think I’m going to mess around with the scripting on the interaction controller first a little bit.

Is there at least a function to generate that export XML file for the window from scripting? I guess even having to do that manually wouldn’t be the end of the world. Maybe 50-60 windows per project is still a lot better than that with hundreds of components per window to look through.