[Connect Update 16 .NET] How do we update UI if Async or Background worker is not allowed?

Question

I was reading a thread from a few years ago that talked about an issue I am having now, I have a WPF application that has a long running process iterating files, I would prefer to run this process as a Task in a background thread, either by using backgroundworker or async, but it appears that Microsation does not allow you to load a DGN file from non-application thread. 
 Is there a way to update the UI and keep it responsive during this process? In VBA there's DoEvents, it doesn't release the UI but it does allow it to be refreshed/repainted. Any options on this?

Mangesh.Shelar · Accepted Answer

Hi Victor, 
 Can you give a try to the following approach? 
 1. Create a new class inheriting Bentley.DgnPlatformNET.Host. 
 for e.g. internal class DgnHost : Bentley.DgnPlatformNET.Host 
 2. Inside your Task/Async method. Before using any DgnPlatform API, write the following. 
 // Initialize Host for DgnPlatform Bentley.DgnPlatformNET.Host session = new DgnHost (); Bentley.DgnPlatformNET.DgnPlatformLib.Initialize (session, false); 
 For UI 
 You need to update your UI on the main thread. Try to implement some mechanism to post progress from Task/Async method. 
 And on that UI update event, update your UI like: 
 System.Windows.Application.Current.Dispatcher.Invoke(() => { //code to update UI. }); 
 Please give it a try! 
 Thanks, 
 Mangesh

Jan Šlegr · Answer

Hi Viktor, 
 a couple of comments, some based on tests I did in the past, but some are "best guess only" ;-) 
 Viktor_Kulik said: I have a WPF application that has a long running process iterating files 
 What amount of data do you process? The iteration itself is really fast: My experience is over 1 mil. of elements requires one or two seconds, depending what approach is used. So I assume something more complex is done in the iteration? 
 Viktor_Kulik said: I would prefer to run this process as a Task in a background thread, either by using backgroundworker or async 
 I think this statement is wrong for more reasons: 
 
 Async/await construction does not relate to "background thread" topic in any way. Async/await may/may not use another thread, but it does not create a new one (or even a new process). Async/await tells how code is processed in specific synchronization context, but cannot be used to control threads or tasks explicitly. 
 To use Background worker in NET 4.6 is like to buy new car and to use steam engine to drive it. Background worker was implemented long time ago for WinForms, and is treated as obsolete. It is recommended to do not use it in new code, moreover it does not work well with some new NET features (including the discussed async/await). Use Task.Run instead of BackgroundWorker. 
 
 Viktor_Kulik said: but it appears that Microsation does not allow you to load a DGN file from non-application thread. 
 I think that MicroStation APIs, both C++ and NET, behave like STA (Single threaded apartment). It means, every interaction with API (any call to MicroStation) must be done from MicroStation (and so addin) thread. To call API from another thread or process is bad idea and does not work (in better case) or crashes MicroStation (probably). 
 Viktor_Kulik said: In VBA there's DoEvents, it doesn't release the UI but it does allow it to be refreshed/repainted. 
 It works in different way, not in terms of using different threads, because implemented in different context and technology: DoEvents stops current (WinForms, typically VB/VBA)) code, passes control to operating system to allow it to finish all tasks waiting in its queue. 
 Viktor_Kulik said: Is there a way to update the UI and keep it responsive during this process? 
 I think more issues are mixed in your question, and to do not make it misleading, they should be answered separately: 
 Access to DGN data is single-threaded and must be done from addin process. I am not sure whether it is possible to e.g. use DgnFile class to open another file at background from another thread or process, but I assume it's not. 
 MicroStation NET API does not support async/await calls (but some code inside NET API implementation is async, especially delegates). But it does not prevent your (I guess ;-) to implement your code to be called with await. I did not test whether it brings and performance or responsiveness benefits, but I guess it depends a lot on context. 
 When you need to process data , received from DGN / MicroStation API, in another thread , because you expect it slows down data iteration, you have to implement extra layer, responsible for receiving data from NET API and passing them to another thread or task (so NET API is never accessed from another thread). Fortunately, using modern NET Task / Parallel libraries, it's simpler than it was in old NET 2. 
 How to update WPF GUI is completely different topic, not related to threads. MicroStation GUI is mostly standard WPF (which itself is also STA), so you can use solutions discussed e.g. on StackOverflow. If I remember right (I did some tests for one project in the past), in standard MVVM model, the standard approach is to use RelayCommand and to update GUI using Dispatcher. Alternatively, there is DispatcherHelper available in MicroStation NET API, so WPG dispatcher should not be called directly (and code is simpler a bit). 
 But be aware, that GUI update is always expensive operation! WPF is not an exception, every update is internally complex task, when events are routed through object trees. When and how frequently GUI should be updated is about to balance between proper feedback and price you have to pay (how slower the code is). I remember (so numbers are approximate only) whereas iteration of 0.5 mil. of elements takes a second at max., when GUI is updated to show how many elements was iterated, the whole process grow to several minutes. My recommendation is to try to update GUI for every 1% of process, not more often. 
 With regards, 
 Jan

[Connect Update 16 .NET] How do we update UI if Async or Background worker is not allowed?

Top Replies