I have the next Script that I want to execute inside a template to animate the background color:
You have your code in the top level of a script module named “Dropdown” ? That won’t work. You must define a function with your code in a script module, and call the function.
Vision is programming is events based. Components (and components inside of templates, as well as templates themselves once you instantiate them) have a bunch of different event listeners/extension functions. You need to choose which event triggers your script. Do you want it when some property on the component changes? When the mouse is clicked, or when the mouse is released? When something is double clicked? Etc.
Do what was suggested, put this code inside a function, and then decide where the appropriate time to call that function is, which extension function? A simple example for running the function every time a new selection is made on the dropdown would be to put this under the property change script of the component -
from myModule import myFunction
if event.propertyName == 'selectedValue':
myFunction(event.source)
event.source would pass a reference to the dropdown to your function so you could look at the dropdown data and manipulate background color.
Just a side note though, the expression language is pretty powerful, and it looks like your just basing your background color on two named queries. Why not add two custom properties on your dropdown, one for each query result, and then using those values, bind your background color property on an expression that uses those values?
+1 for everything @bkarabinchak.psi said, except that. Don't import from other script modules. You can have code lifetime problems. Always use fully qualified names from script modules. myModule.myFunction(event.source) in the posted example.
@pturmel
You’re saying just to import myModule and then call the fully qualified name? Or is import myModule problematic itself?
import myModule is unnecessary, as other script module names are implicitly imported. from myModule import x is trouble. There have been problems where x gets stuck on old code after edits to myModule. If you feel you must do this, for readability’s sake, do it within your functions, not at the top level.
You’ll have to show more. Your script module code. Your complete runscript expression. A view of your template’s component tree.
This implementation looks familiar to me. This is non-ethical attitude @nelson.hurtado, just do it by your own.
I’ve worked for two days for my own and it doesn’t work, I need some help no more than a clue to reach the solution!
@jespinmartin1 is correct @nelson.hurtado. This is a question from the test, and as such, if you need help on the test, you need to email in to training@inductiveautomation.com for help. Help from other users on the forum is not allowed, as the test is meant to be a test of your efforts and not a group project.