Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>My feeling is that you might not have many options other than running on the UI thread. </p> <p>If it were a case that the long time involved was due to gathering and arranging the data then a background thread would be the best option, and then call any UI dependency properties using the Dispatcher object. I'm assuming the time is not to gather any data it is purely down to programmatic creation of the UIElements.</p> <p>As I understand it UI elements derive from <code>DispatcherObject</code> that gets the <code>Dispatcher</code> from the current working thread so that rules out creation of controls on another thread.</p> <p>Then all Dependency Properties call <code>Dispatcher.VerifyAccess</code> when written to, that will raise an exception if accessed on the wrong thread. So that rules out updating databinding and properties on a different thread.</p> <p>My first reaction would be like @Kent wrote.<br> To elaborate slightly, if you have a <code>foreach</code> loop for each row with another <code>foreach</code> for each column then you could, even though you are in the correct UI Thread, call <code>Dispatcher.BeginInvoke</code> to "yield" momentarily from your long running method. i.e to break it up and then pass control back to the UI thread to later carry on adding to the grid. The layout effort might be significantly greater and the overall time would be longer but a bit more responsive.</p> <pre><code>private void Window_Loaded(object sender, RoutedEventArgs e) { CreateRow(1); } private void CreateRow(int i) { // // Construct row i of the grid // Dispatcher.BeginInvoke(DispatcherPriority.Background, new EventHandler(delegate { CreateRow(i + 1); })); } </code></pre>
 

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