Need help with backgrund thread and UI blocking

[MrNorth]

Hi!

On our wpf vb.net application we have a button "generate report". The report will be opened as a pdf to the user when finished. These are the steps involved:

1) Show a panel to the user with a spinning progress indicator showing "generating report"

2) Load data from database (background thread)

3) Pass the data to a report component and use it to generate a pdf (required to be on UI thread because of the component internals, get exception otherwise)

4) Use Process.Start and launch pdf reader with the path of pdf supplied in 3

5) Close progress panel

You can see the problem? I have a long running task required by 3rd party component to run on UI thread (STA) and that is effectively blocking the spinning progressbar that is also running on the UI thread. The end result from this is very choppy visuals.

How can I solve this? Can I have multiple UI threads or use Task.Run somehow to cheat the 3) so the component thinks it is running on UI thread when not?

Any ideas?

/H

[Sitten Spynne]

I'd call that a pretty terrible reporting component and seek a better one. But I've been there, and know that you probably can't. Let's just agree that's what we'd do if we had the chance and look for a workaround.

The next-best thing to do I can think of is to create a 2nd program that is designed to take command-line args, create the report, and somehow transmit information about that report back to the caller. If it's just a PDF, it can save the file to a place you tell it.

Then the process would be:

1. Show the progress indicator.
2. Load data.
3. Start the secondary program and wait for it to indicate it's finished.
4. Display the PDF.
5. Close the progress panel.

If you start another program, that's technically another thread, but it will be STA and have all the things the component expects from a UI application. It's a little complex to coordinate compared to another in-process thread, but it's possible. The difficulty here is answering, "How does it 'talk back' to the original application?" but if it's just creating a PDF then "It finished" might be all the communication you need.

[MrNorth]

I'd call that a pretty terrible reporting component and seek a better one. But I've been there, and know that you probably can't. Let's just agree that's what we'd do if we had the chance and look for a workaround.

The next-best thing to do I can think of is to create a 2nd program that is designed to take command-line args, create the report, and somehow transmit information about that report back to the caller. If it's just a PDF, it can save the file to a place you tell it.

Then the process would be:

1. Show the progress indicator.
2. Load data.
3. Start the secondary program and wait for it to indicate it's finished.
4. Display the PDF.
5. Close the progress panel.

If you start another program, that's technically another thread, but it will be STA and have all the things the component expects from a UI application. It's a little complex to coordinate compared to another in-process thread, but it's possible. The difficulty here is answering, "How does it 'talk back' to the original application?" but if it's just creating a PDF then "It finished" might be all the communication you need.

The component in question is called oxyplot and we use it to generate graphs. The call we use is actually an api call that can generate xaml from a PlotModel, and somewhere inside the api I get an exception that non STA calls are forbidden. We then use this xaml and render a page which we convert to pdf using our own xamltopdf component (that can be called from any thread).

Yes it is a shame, but since we are using this component to render graphs on many diffent places we felt it was only natural to use it to render pritned reports as well since it can output to xaml.

/H

[Sitten Spynne]

Yeah since it uses Xaml it unavoidably becomes a UI type, this is one of the more agitating things about WPF. You can /make/ a thread STA, but I get the feeling if it were that easy MS would just publicize how to do it. My guess is "it must be STA" is just the first requirement. Anyway, I'm still sticking with what I said. The "best" solution here will probably be a secondary helper exe.

At the very least, it will work and let you keep producing results while you research a better solution on the backburner. I like writing elegant things, but I get paid to produce results. It's a balance!