Property changed event firing when I don't expect it to

Ignition
1

I have 3 drop downs, one is unrelated to the other 2, but the 2nd populates its data based off the selection of the first one.

Example:
image
Initially I thought that changing the ‘Select Project’ drop down was setting the Select Task drop down’s value to -1, but upon closer inspection, it was not.

So I wrote a script on the property change event that just sets the selected value of Select Task to -1.
The whole script:

event.source.parent.getComponent('Task Selector').selectedValue = -1

This is under the propertyChange event handler of the Project Selector drop down.

This led to other issues that I didn’t foresee, though. Occasionally the Task Selector drop down will change its value to -1 without any input from me, and occasionally it will change to -1 when I press my button to confirm our task.

EDIT: It actually sets the dropdown back to -1 once every roughly 2 seconds or so, which I think is my polling rate for the above drop down.

If anyone has any insight, I would really appreciate it.

2

Vision?

If so, this is expected behavior for components that display rows from a dataset. When a new dataset is applied while a row is selected, the component briefly sets the selection to None (-1), sets the new data, then conditionally restores the selected row. Conditionally, because the new data might not have that row, and the selection will remain -1.

The simplest solution in a case like this is to not poll. Let the bindings run on window startup and then only on changes to their references.

3

So what would be your recommendation for this then? Changing this:
image
to off? Would it still fire my query on window open?

EDIT: Yep, that fixed it.

Thank you so much @pturmel

4

Yes, off. And yes, it will run at least once.

FWIW, I almost never use polling for queries. Once on open, then deliberate re-triggers using system.db.refresh when some other event indicates the need for fresh data. (If not handled by a change to a reference.)

5

I see. That makes sense. I inherited this project from someone else, and they let essentially every component poll, so I was simply following in their footsteps, but didn’t realize that polling changed the property for a brief moment, but that does make sense.