What happens if a running script is "interrupted" by a save/push to the client?

Can I expect the unexpected? Will the script pick up where it left off? I have a user interaction on my client screens that seems to get buggy when I’m saving repeatedly on the gateway. I’m wondering if this might be the root cause.

In Vision? I would expect the script to run to completion, uninterrupted, with the object contexts (old) it started with. Any system.* calls looking up other objects will be unreliable, as the point of switchover is not documented.

So a system.tag.write or system.tag.read would probably be unreliable?

I should elaborate. My script reads/writes some client tags, does some stuff with that information, and then does some more reads/writes to client tags.

I don’t recall if pushing/updating a project replaces all of the client tags. It must at least add/remove any changes to them from the designer. The system.tag.* functions should work, but you might write an update to one, changes arrive, and then read back something unexpected.

Keep in mind that all of your scripts will be replaced by the update. You can detect the reload with code in the top level of a script module. The dictionary from system.util.getGlobals() will let you hold onto old code or objects to intelligently transfer state to new code and objects.

Consider using script module top-level dictionaries as non-divisible state management tools. Old code will work only with the old dictionary, new code will work with the new dictionary.

From what I’ve seen any active client will remember it’s tags after an upate. It just occurred to me that I do some system.gui.transforms() in my clients also. All my symptoms would make sense if a pushed update was killing this function.

Well, the update wouldn’t kill the the transform() operation, just make its target invisible on its way to garbage collection, since the update will recreate all open windows.

1 Like