# writeBlocking in a Vision Client **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting, ignition80, vision\ **Created:** [July 28, 2022, 7:53pm UTC](https://forum.inductiveautomation.com/t/writeblocking-in-a-vision-client/62427 "2022-07-28T19:53:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![BryanB](https://avatars.discourse-cdn.com/v4/letter/b/57b2e6/32.png) [@BryanB](https://forum.inductiveautomation.com/u/BryanB)\ **Post date:** [July 28, 2022, 7:53pm UTC](https://forum.inductiveautomation.com/t/writeblocking-in-a-vision-client/62427/1 "2022-07-28T19:53:22Z")
I was reading through one of the Knowledge Base articles ([https://support.inductiveautomation.com/hc/en-us/articles/5876672308877-Vision-Client-Unresponsive](https://support.inductiveautomation.com/hc/en-us/articles/5876672308877-Vision-Client-Unresponsive)) and came across the section "Check for Any Blocking Functions Running Directly in the Client". This section states: > You generally do not want to run blocking functions in a Vision Client, especially if there are multiple such scripts in the Client. As an example, Java Swing’s GUI is generated with a single thread. This thread is called the **event dispatch thread (EDT)**. It is generally bad practice to run blocking scripts in the Vision Client because this can block the EDT. With this, should I be using system.tag.writeAsync for the majority of writes that I need to do in a Vision window (if a dropdown changes, go write the new value in the PLC)? Should I be creating bindings that I update and have Ignition automatically update the PLC variable? What is best practice for writing values in a Vision Client? ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [July 28, 2022, 8:40pm UTC](https://forum.inductiveautomation.com/t/writeblocking-in-a-vision-client/62427/2 "2022-07-28T20:40:31Z")
> [@BryanB](#): > > Should I be creating bindings that I update and have Ignition automatically update the PLC variable This. You should use binding (direct or indirect) whenever possible. In almost all cases tag write functions can, and IMHO should, be replaced by a custom property with a bi-directional binding. For instance: ```auto system.tag.write*(['[default]path/to/value1'],[100]) ``` Could also be something like: ```auto event.source.customPropertyValue1 = 100 ``` Where `customPropertyValue1` is bound to `[default]path/to/value1` In the event that you need to write a value to a tag in script and time is not critical then use`system.tag.writeAsync()` If you need to insure that the values are written prior to continuing with another action, then `system.tag.writeBlocking()` is needed. In this case you can utilize `system.util.invokeAysnchronous()` to run on a background thread. If you need to effect changes to UI components, then you can utilize `system.tag.invokeLater()` to accomplish that. Here is a discussion on a similar topic, it relates to V7.9 but the concepts still apply. `writeSyncronous()` and `writeAllSyncronous()` have been replaced with `wrtieBlocking()` in V8. > [@Need help understanding system.tag.writeAllSynchronous()](https://forum.inductiveautomation.com/t/need-help-understanding-system-tag-writeallsynchronous/24316/8): > > Why do you want to read the tags immediately after you have written them? writeAll is an asynchronous function, so it moves on to the readAll before the writes have actually completed. Read all on the other hand is not asynchronous. It will read the values of the tags at that time which may or may not be after the write has occurred. What are you expecting to happen to the tag values that you need to read them again after the write? Is the controller modifying them? You could use invokeLate… ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 29, 2022, 12:33am UTC](https://forum.inductiveautomation.com/t/writeblocking-in-a-vision-client/62427/3 "2022-07-29T00:33:31Z")
The recommendation is for the EDT, the foreground thread. All UI events run on this foreground thread. If you run a system function that has to contact the gateway, the foreground of the Vision client _ **stalls** _ for the round trip. If you are making such calls in many events all over the place, the UI will lag, especially on a WAN or VPN. The deprecated `system.tag.write()` call is one of the few that **isn't** a problem, because it is really Async without the callback. Fire and forget, so to speak, and doesn't stall the UI. (It may be deprecated, but I don't see any of the deprecated functions going away any time soon.) Note that the `actionPerformed` event on a button, because it is user-initiated, is generally an OK place for one or two such calls. Anything more complicated should be delegated to a background thread, where there won't be any UI interaction. However, background threads cannot update the UI themselves--deadlock risk. See this topic for more information: > [@Update GUI via Asynchronous thread](https://forum.inductiveautomation.com/t/update-gui-via-asynchronous-thread/9666): > > I’ve got a script I am experimenting with that can take a lot of time to execute, so I now use the system.util.invokeAsynchronous to run the script in a separate thread to keep the GUI from locking up. I am using the asynchronous thread to copy files from one place to another, and I would like to show the progress of the file copy with a progress bar. How would I go about this? I am importing a few python libraries to do this. import shutil def fileTransfer(): path = system.file.openFile() …