# Non-responsive UI thread detected. Stack saved at ... But I couldn't find where exactly **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting, vision\ **Created:** [June 19, 2026, 8:42am UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073 "2026-06-19T08:42:21Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Hamza\_TM](https://avatars.discourse-cdn.com/v4/letter/h/c0e974/32.png) [@Hamza\_TM](https://forum.inductiveautomation.com/u/Hamza_TM)\ **Post date:** [June 19, 2026, 8:42am UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/1 "2026-06-19T08:42:21Z")
Hello, I have developped a vision application that visualises production data using multiple named queries. The application works so fine, except that sometimes it freezes (not responding) for a couple of seconds. In the diagnostic I found this entry many times : " **Non-responsive UI thread detected. Stack saved at ...**" When I open the stack, I couldn't really identify where the issue exactly is .. if anyone can help. Attached is an example of the saved stack. [NonResponsiveEdt-2026-06-19\_100328.json](https://forum.inductiveautomation.com/uploads/short-url/yBFt6hXQMm44fZltIHOqOyI1Jwr.json) (50.0 KB) ---
**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:** [June 19, 2026, 11:56am UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/2 "2026-06-19T11:56:35Z")
The very first thread in that dump is running a named query from a custom component method (`updateDailyTrefilage`). Which is running from a property change event. That event runs in the foreground thread, and any delays will freeze the UI. Run your named queries from named query bindings. If you absolutely have to use scripts, learn to use `system.util.invokeAsynchronous` safely. ---
**Author:** ![Hamza\_TM](https://avatars.discourse-cdn.com/v4/letter/h/c0e974/32.png) [@Hamza\_TM](https://forum.inductiveautomation.com/u/Hamza_TM)\ **Post date:** [June 19, 2026, 7:11pm UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/3 "2026-06-19T19:11:13Z")
Thank you @pturmel for your valuable hint. In fact I have built my whole application on running multiple named queries on a script fired upon a property change .. which makes sense to the unresponsive UI thread issue I have. The problem now is that I am doing further complex calculation (production KPIs, ratios ...) in my script upon the queries results ... which will be difficult to do on binding directly ... I guess now I have to review the whole building of my project. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [June 19, 2026, 7:23pm UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/4 "2026-06-19T19:23:19Z")
Scripts are automatically invoked on the EDT for thread safety when interacting with Swing, but you can always do your own heavyweight processing in an asynchronous thread and move back to the EDT yourself. That's the entire raison d'etre of the `system.util.invokeAsynchronous` function Phil mentioned. Basically: 1. On EDT, user triggers your script by some action 2. On EDT, script gathers whatever state it needs from the GUI, including enough information to 'call back' when the computation is done 3. Script passes that state in as arguments to a dedicated function (ideally in your project library) that will run asynchronously 4. Once the script logic is complete (or at various checkpoints to report progress) script uses `system.util.invokeLater` to push callbacks on to the EDT. ---
**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:** [June 19, 2026, 7:29pm UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/5 "2026-06-19T19:29:44Z")
Deep discussion here: > [@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() … Yes, old but still applicable. ---
**Author:** ![Hamza\_TM](https://avatars.discourse-cdn.com/v4/letter/h/c0e974/32.png) [@Hamza\_TM](https://forum.inductiveautomation.com/u/Hamza_TM)\ **Post date:** [June 22, 2026, 6:17pm UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/6 "2026-06-22T18:17:27Z")
Thank you @pturmel and @paul-griffith for your support and help. I'd be honest to say that I was suspecting my need for an asynchronous call method, but I am not used to multithreading in general (and in ignition in particular) so it is kind of a big topic to me. My problem was solved by simply using an `system.util.invokeAsynchronous` .. literally this little change made my application works without problem .. Even more, my application is now running more smoothly as the updates are taking place gradually as the script executes (not like before where the screen was freezed until all components are updated at once). For the record, and to help further users who will stumble across the same problem, I made a short comparison diagram : ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/f/4fee31e17658079c68aa4cbfa834070abc5923d0.png) PS. This diagram may contain mistakes but it is just to make up my mind 🙂 ---
**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:** [June 22, 2026, 6:25pm UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/7 "2026-06-22T18:25:28Z")
The diagram is **BROKEN**. You **cannot** update the UI components from that background thread. It may appear to work, but will intermittently **crash** your Vision client. Go back and re-read the old topic I linked. And property access (read or write) or method calls on components **must** occur on the UI thread. Use invokeLater to fire off such actions. ---
**Author:** ![justinedwards.jle](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justinedwards.jle/32/37854_2.png) [@justinedwards.jle](https://forum.inductiveautomation.com/u/justinedwards.jle)\ **Post date:** [June 23, 2026, 2:11am UTC](https://forum.inductiveautomation.com/t/non-responsive-ui-thread-detected-stack-saved-at-but-i-couldnt-find-where-exactly/116073/8 "2026-06-23T02:11:04Z")
Refactor your custom methods for "heavyweight calculations" to the script library, and then you can call them as needed from whatever function was invoked asynchronously. Any swing component property values that are needed for the calculation must be packaged up and delivered to the asynchronous function as arguments via the invokeAsynchronous call. Use a nested callback function that can supply the return values to the EDT via invokeLater. It is safe to deliver a swing component as an argument to an asynchronous function and pass it around, and this is sometimes necessary for getting return values to the desired place, but **do not** touch any of the component's properties or methods outside of a callback function that is called using invokeLater.