Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<ol> <li><p>It depends. You've shown a lot of code, and yet omitted the one bit that you're actually asking a question about. First, without knowing what the code is we can't know if it's actually going to take a while or not. Next, if you await on a task that's already completed it will realize this, and not schedule a continuation but instead continue on (this is an optimization since scheduling tasks is time consuming). If the task you await isn't completed then the continuation will still be executed in the calling <code>SynchronizationContext</code>, which will again keep the UI thread busy. You can use <code>ConfigureAwait(false)</code> to ensure that the continuation runs in the thread pool though. This should handle both issues. Note that by doing this you can no longer access the UI controls in the <code>...</code> sections of <code>ProcessScriptAsync</code> (without doing anything special). Also note that since <code>ProcessScriptAsync</code> is now executing in a thread pool thread, you don't need to use <code>Task.Run</code> to move the method call to a background thread.</p></li> <li><p>That's one option, yes. Although, if you're updating the UI based on progress, that's what <code>IProgress</code> is for. I see you're using it already, so that is the preferable model for doing this. If this is updating a separate type of progress than the existing <code>IProgress</code> you are passing (i.e. the status <em>text</em>, rather than the percent complete as an int) then you can pass a second.</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload