this is always a constant list, thus the only thing that can change here is event.source.text
Try putting it in a library script, so the actual event script only grabs the parameters and passes them to the function. Isolate things to reduce unexpected behavior:
library script:
def func(user_input, tag_path, table_name, start_time, end_time):
id_list = system.tag.readBlocking(tag_path)[0].value.getColumnAsList(0)
if user_input not in id_list:
return False, None, None
query_params = {
'tableName': table_name,
'start': start_time,
'end': end_time,
'user_input': user_input
}
count_result = system.db.runNamedQuery("countStop", query_params)
duration_result = system.db.runNamedQuery("calculateDurationStop", query_params)
return True, count_result, duration_result
event script:
if event.keyCode == event.VK_ENTER:
folderPath = event.source.parent.dataPath
flowVar, count_result, duration_result = func(
user_input = event.source.text,
tag_path = "{}/AlarmData/alarmList".format(folderPath),
table_name = "Alarm_{}".format(folderPath.rsplit("/", 1)[1])
start_time = system.gui.getWindow("Standard Window/Alarms").getRootContainer().getComponent("Cal_Start").date,
end_time = system.gui.getWindow("Standard Window/Alarms").getRootContainer().getComponent("Cal_End").date
)
2 Likes
So you are saying you have a printout from a text value that is not inside the string list yet still returned true? on a script that only runs once.
if so plz provide a screenshot of this and give us this list and value to see if its repeatable
I found the problem. you were right, it definitely has something to do with the assignment. I have commented all code lines and then removed the comments line after line and the problem occurs exactly when I add those two lines.
But how to avoid this assigment then? Is there an embedded function to display a value using a label component?
I can not publish the exact values, but I think this should be repeatable with random values too
This doesn't make much sense:
Those lines are IN the if scope, there's no way they can effect whether the if gets executed or not.
1 Like
No i cant, i can not replicate the behaviour you are describing.
If find something that works on static values in one script (without going to tags so everyone can run it), please share
You are right, I can also not replicate the error with a static list in the script. But how should the Tag be a problem? It is just a memory dataset and there is no write-operation on it anywhere.
Let's take a few steps back and try to reduce the example size, maybe we can pinpoint where exactly things are going wrong.
Add a button and use it to trigger a script like this:
ids_list = system.tag.readBlocking(["path to one of your dataset tags"])[0].value.getColumnAsList(0)
print ('some_invalid_input' in ids_list)
print ('some_valid_input' in ids_list)
If this shows the correct behavior, add things in little increments:
- get the input from a component instead of using a literal
- put the script on a key event instead of a button
- etc.
If you find a situation that reproduces the error, start examining everything very carefully.
When you assign to a component property, and that property has its own change monitoring, the side effects will start immediately--recursively--before the current script ends.
2 Likes
I tried it. It works when triggered with a button. And it's now also working within the keyPressed event. I think, I will let this functionality by side first because it is not reliable for the moment.
Thank you
Okay thank you, I can not avoid assigning, since I want to display a value with a label component.
i think you should not just let this go to the side, there is clearly something wrong with the way this is getting handled, you might repeat a similar mistake somewhere else
Then do that assignment last, outside any loop.
(Is something binding to that label's text? That would feed back into a change that triggers your original code?)
I'm working with ignition in Trial Mode , maybe the behaviour will be different in the production mode?
No, trial mode and production mode are identical for Ignition itself. (3rd party modules might have differences, but not likely.)
No there is no binding, but there are multiple write-operation on the label at different places within the project
well that is really weird, you dont use a label to store date, you should use a tag, and write stuff to the tag and let the label read the tag.
For things that can change per user, use a client tag, so everyone can filter on their own
Might want to use a custom property or top level script variable, depending on the scope that the data needs to be persistent in.
this sounds like a client tag to me, its a vision project so this should be fine no? (i dont really work with vision)