Reputation: 10865
I know that I cannot spawn different threads and put it in the UI thread to add it in the Visual Tree as it will throw an exception that it cannot access that object because a different thread owns it.
My current scenario is that I am heavily creating UI controls runtime, say like 200 (FrameworkContentElement) controls and add it to the DockWindow. Is it possible for me not to freeze the UI while creating this and try to load them to the UI thread? I cannot even show a progress dialog because that will use the UI thread while showing the dialog while doing work on another thread, that is okay if what I need to handle is data and put it in the UI but this time I need to create these UI controls.
One approach I've thought is create the UI controls and serialize them into MemoryStream and load them to the UI thread, one problem in here is that I have to re-attach the DataContext to the controls but that is fine, at that moment I can delegate it to another thread. Problem still is that is this feasible to do?
I tried mixing Task and Thread object to make the ApartmentState to STA but still no luck.
public static Task<T> StartSTATask<T>(Func<T> func)
{
var tcs = new TaskCompletionSource<T>();
Thread thread = new Thread(() =>
{
try
{
tcs.SetResult(func());
}
catch (Exception e)
{
tcs.SetException(e);
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
return tcs.Task;
}
EDIT: These controls again are FrameworkContentElement, virtualizing controls in this scenario won't help. This is with FlowDocument controls creating the controls in runtime. Say, Runs, Tables, Paragraphs, etc.. Therefore, ListBox, TreeViews, etc are not applicable in this scenario.
Upvotes: 4
Views: 465
Reputation: 11040
200 controls shouldn't pose that big of a problem to render WPF on a decent machine can take a few thousand primitives.
You can show a progress bar while loading your data and while parsing it. Then you can throttle creating the UI elements if needed by having and off-UI-thread process loop over your data and call UI thread to instantiate controls. You can even separate instantiations by a small sleep to let the screen render, but only use this for VERY heavy UI...
... that being said - if your UI is so heavy you're probably designing it wrong. The question should not be "how many UI elements can I put before my UI slows down to a drag?" but "what's the smallest number of active UI elements that can do the job?".
The word "active" refers to the approach taken by listviews where the actual items are virtualized - they are only created as needed and disposed if not visible. So instead of a DockPanel consider using a virtualizing container, such as a ListView, if your UI allows for it;
I can elaborate further if you can provide an example of your specific UI elements.
Upvotes: 2