Thanks for your reply.
I think I will try like this.
But is there case where a dedicated thread (with infinite loop) should be better ? What are the elements to take into account when choosing between the 2 solutions?
The difference would be the speed you need to be able to react to a change i guess. (altho depending on the tag there isnt rly a difference as most use a time basing polling too)
What exactly are you trying to track that you think would need a dedicated thread?
if something in the db changes that you would need to be aware of as fast as possible you should send out an event from the db on changes or even send out an event at the same time you send your updates to the db
You almost never want to do an infinite loop in Ignition. You can do while loops if there it will eventually exit, but a while True: without a break is never going to be good in Ignition. View it like this - the timer script should say how often the loop logic should run, the part inside your infinite loop.
Based on tag change - it depends.
It could be based on a PLC tag and in your tag change event you inspect the currentValue and previousValue and go from there.
It could be based on an expression tag which you can incorporate some logic into, something like {tagA}>10 && {tagB}<0 && dayOfWeek(now(1000))=1 if tagA is great than 10 tag B is less than 0 and it's a Sunday, you can make it however you want.
Or you could make it a simple memory tag that is a boolean that you write True to to trigger the event from a variety of spaces - though in this case you could replace this with system.util.sendMessage | Ignition User Manual
To show the result of these gateway tag change events you have two options - 1) write to tags, and in the client you have components that are bound to these tags or 2) use system.util.sendMessage to send a message to the clients to be handled with a client message handler which you then have free reign to do anything with - open a popup window, play a noise, whatever you can script.