Click here to Skip to main content
11,647,644 members (66,337 online)
Rate this: bad
Please Sign up or sign in to vote.
See more: C# WPF Threading
hi, i have problem in the following code:
System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ThreadStart(() =>
    viewer.c1DocumentViewer.Dispatcher.BeginInvoke((Action)(() =>
         viewer.Report = this;
t.IsBackground = true;
The generate function generates a Report with about 6 pages, during the generation everything works fine and my GUI does not freeze. But when i call BeginInvoke to set my generated Report in the Report Viewer the whole GUI freezes for about 6 seconds. How can i avoid freezing my gui? Thanks in advance, manu
Posted 1-Apr-12 4:55am
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

This code can be improved, but I don't think you can easily make UI more responsive. Basically, you think correctly. Just one thing: in this case, Invoke is a bit better then BeginInvoke, but I don't think you can see a big difference (but try it). Creation of a thread this way is expensive (there are three alternatives which are faster), but you did not report any observable delay before the invocation of the viewer property. It looks like the only time-consuming operation is the rendering of the viewer content, but you the assignment should be performed through the dispatcher as you correctly do, anyway; and the rendering itself is done in a separate rendering thread. I would experiment with the following: could you generate a new report if the same size and assign it to the viewer again. Does it take the same time? If it always the same, I would think about starting with a very short content and appending small pieces one by one from your separate thread. It would make total time even more, but could keep the UI responsive. After all, I don't know why 6 pages could be so slow. Maybe the simple reason is that the C1DocumentViewer class sucks. Smile | :)
Björn Ranft at 1-Apr-12 12:36pm
Hi SA, I would also give a try with Backgroundworker-Class, do you agree?Regards
SAKryukov at 1-Apr-12 14:36pm
Agree? Surely, I have nothing against Background worker, it would do better then the present code, but I'm pretty much sure: it won't solve the problem. You see, OP already reported that Generate does not make a delay, but Generate is called when the thread was already created and started. Therefore, everything before the call to BeginInvoke is not a source of the problem. --SA
m.bleimuth at 2-Apr-12 14:43pm
please have a look on my comment to the Backgroundworker...
m.bleimuth at 1-Apr-12 14:56pm
I found out what's happening exactly: System.Threading.Thread t = new System.Threading.Thread(new System.Threading.ThreadStart(() => { Generate(); FixedDocumentSequence fds = _doc.FixedDocumentSequence; viewer.Dispatcher.Invoke(new Action(() => { viewer.c1DocumentViewer.Document = fds; })); })); t.SetApartmentState(System.Threading.ApartmentState.STA); t.IsBackground = true; t.Start(); the FixedDocumentSequence Property only generates the Sequence by getting the Value, so this takes a lot of time. But now i have the problem that i cant load the fixeddocumentsequence into my viewer. It always throws an InvalidOperationException that says that the PageSequence has an aifferent thread as owner. So how can i load the FixedPageSequence into the viewer, i thought invoking the viewer dispatcher should be enought?
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

There is a Priorityproperty on the Thread([^]). I If you reduced the priority, maybe reducing the priority will help.
Clifford Nelson at 3-Apr-12 4:39am
So I was downvoted without a comment. I am interested in knowing why priority would not work?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 500
1 F-ES Sitecore 370
2 OriginalGriff 322
3 DamithSL 315
4 CPallini 240
0 OriginalGriff 1,342
1 994
2 DamithSL 971
3 Sergey Alexandrovich Kryukov 873
4 CPallini 795

Advertise | Privacy | Mobile
Web02 | 2.8.150804.3 | Last Updated 1 Apr 2012
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100