LabVIEW Web UI Builder and Data Dashboard

cancel
Showing results for 
Search instead for 
Did you mean: 

Web UI Builder Event Script Property Error

I'm using an event script to enable/disable some controls on my front panel.  Most of the time it works fine but occasionally I see an error pop up on the start that reads the following:

 

"Cannot find control name or cannot find attached property on the current control: 'control name'.Value"

 

It also comes up with differnet properties like .IsEnabled.  It seems to be happening randomly.  Here is one of my scripts

 

control = runtime.GetProperty("LubeRemBool.Value")

if control == False:
     runtime.SetProperty("Bearing Pump-out.IsEnabled", False)
     runtime.SetProperty("Bearing Bleed Valve.IsEnabled", False)

 

and I have that run on PropertyChanged with property Value.  Anything glaringly obvious?

0 Kudos
Message 1 of 8
(8,329 Views)

I do not see anything obviously wrong.

 

The next step should probably be to prevent the error from appearing as "random" and start to narrow it down to something we can troubleshoot.

 

Does it happen with all controls or only some?  

Is there an event that takes place that is likely to cause this error?

Has the code ever worked for you?  If so, what has changed since it was working?

Are some controls more likely to throw the error than others?

0 Kudos
Message 2 of 8
(8,293 Views)

I am using a tab control and it looks like if a script event is triggered on a different tab than the tab I startup on this error will pop up, but it doesn't look like it is happening to all of the items in the script or even to every script event that would have been triggered in the tab.  After startup all of the events work fine, even the ones that had thrown the error.

 

edit: It also looks like if the script is triggered from a different tab than the control being changed is on this error will pop up as well.

0 Kudos
Message 3 of 8
(8,284 Views)

I want to make sure I understand the edit correctly.

 

You have several tabs.  Let's call them A, B, and C.

 

Your program starts up with one of the tabs.  Regardless of which tab starts up, all of the controls on that tab can be run without error.  So if A starts, we can call everything from A.  But, controls from B and C throw the error.

 

If we change to tab B, we can now work with controls from tab B without error.  But, working with A and C now throw the error.

 

If we change back to tab A, the behavior goes back to A working while B and C throw the error.

 

Does that sound about right?

0 Kudos
Message 4 of 8
(8,264 Views)

Yes that seems to be the case.

 

Might be irrelevant, but only the first control called out on the other tab shows up with the error.  I'm thinking the script just stops there.

So I am on tab A and a script runs that should change several controls on tab B.  Only the first control changed on tab B in the script comes up with that error, but still when I go to tab B all of the controls haven't changed.

0 Kudos
Message 5 of 8
(8,261 Views)

It appears to be expected behavior for unselected tabs to not keep their contents active in memory.  If this is the case, we would want to consider the application's architecture.  Is there something preventing placing controls dependent upon each other in the same tab?  Is it possible to make a change to the Block Diagram element, perhaps using Case Structures?

0 Kudos
Message 6 of 8
(8,245 Views)

Well I am testing right now with a control in a separate tab changing the control in another, but in future a web service will be writing a boolean to change a control action and I thought if I was not on the right tab at the time this problem could come up.

 

I should be able to switch this over to the block diagram but I was hoping to keep it in python since it seems (to me) that it is simpler that way.  I have other scripts with if..elif statements which just makes a little bit more complicated block diagram.  I'll get back to let you know if this problem persists after moving the script functions to the block diagram.

0 Kudos
Message 7 of 8
(8,235 Views)

The Block Diagram does not have to be a permanent transition.  It is generally is "easier" to get code working as you would expect within the LabVIEW environment if this option is available.  Once you know it works, it is quick to transition to your desired development environment.  Similarly, this helps you determine how much of a role your code plays in the problem.  The first post made it sound like you were unclear about your code.  This would be a good first step to help eliminate that as a cause.

0 Kudos
Message 8 of 8
(8,216 Views)