Re: Running a form in a diferent Thread - C# Discussion Boards

5-May-08 4:07

Hi there,

First of all let me say that I tried to find this here in codeproject and google... but I think I'm missing the keywords to find what I want.

What I'm looking for I think it is pretty common.
The thing is... after learning about delegates and threads and trying to implement it in my project I'm still having a freez while the client draws grids.

Let's go to the details:
I have a mainprogram that calls diferent forms from its menu.
One of this forms needs to draw graphics and (Xceed) Grids with lot of data.
The problem: while drawing these graphics and grids, the whole program freezes (all open forms, this form and the mainprogram).

While trying to solve this problem I started researching about delegates, threads and everything else that popped up in the articles. With all I learned I was able to do some things in my project that increased its performance. But in this particular problem, even when the "drawing function" is put in another thread, the mainprogram continues to freez.

I really want to understand why this is happening and how to solve this, so please tell me if I'm wrong.
I'm guessing that the problem happens because the "drawing function" needs to be runned in the same thread as the "form creator" thread, in this case the mainprogram. This way, although the "drawing function" is called through a delegate, its begin starts with "if (this.invokeRequired) this.Invoke" to avoid cross threading problem.

I don't really know in wich thread the "this.Invoke" will execute my "drawing function" but I'm almost certain that is in the mainprogram's one. So it will keep on freezing.

With this in mind I looked in google and here at codeproject the only way I though of to solve this: a way to run the Form in a diferent thread from the mainprogram. Just like as it was a diferent process. This way the "this.Invoke" would call the paralel thread that runs only the Form, and not the whole mainprogram, stopping the freez problem.

I didn't find something that made me do this succesfully and that brings me here.
Can anyone teach me a way to work around this problem? If there is a way to solve this without creating a thread for this form alone, please, I would like to hear it (if creating a thread is a solution at all... I really don't know).

If I said something wrong, I'm sorry, I'm still a jr here. Please tell me so I can learn better about this.

Thanks in advance,
Oscar

S. Senthil Kumar5-May-08 5:34

S. Senthil Kumar

5-May-08 5:34

What exactly is taking time? The drawing of data or the loading of data to memory?

I'd be surprised if it's the former - datagrids are usually built to show large amounts of data without freezing.

And yes, you're right, Invoke will execute the delegate passed to it on the UI thread. Can you paste the code (or atleast pseudocode) which you think is taking a long time to complete?

Regards
Senthil [MVP - Visual C#]
_____________________________
My Blog | My Articles | My Flickr | WinMacro

oscarderooij6-May-08 2:29

6-May-08 2:29

Hi there Senthil,
First of all thanks for the answer.

What is taking time is the drawing of the data. In our project we use a component called Xceed Grids for better visualization of the data. I dunno if it is quick or if it is slow.

All the data come from a XML that my project receive, all the processing of the document don't take much... the problem is exacly in the function that draws all the grids and the grafics.

The code that takes long is a part of the Xceed Component where we creat the grids.
For instance:

<br />
        Agrid.BeginInit();<br />
         Agrid.Clear();<br />
<br />
         // Adiciona Headers<br />
         //Agrid.DataRowTemplate = new LEFModeloLinhaGrid();<br />
         Agrid.SynchronizeDetailGrids = true;<br />
         ColumnManagerRow cmrNovo = new ColumnManagerRow();<br />
         Agrid.FixedHeaderRows.Add(cmrNovo);<br />
         ((ColumnManagerRow)Agrid.FixedHeaderRows[0]).AllowColumnReorder = true;<br />
<br />
         // Adiciona as colunas do nível 1<br />
         Agrid.Columns.Add(new DataBoundColumn("Groups"));<br />
         Agrid.Columns["Groups"].Fixed = true;<br />

And many more Agrid.Columns.Add
After that We add detailGrids and we must for each column padronize a style.
The foreachs dont take long... almost nothing... the problem is when we run the

"Agrid.Endinit()".

That's the Xceed Grid method that actually draws everything.

If it was only one grid, everything was ok... but we have many grids like that one above to be drawed in sequence and shown in diferent tabs.

Well, did this give some more information?
Thanks in advance!

S. Senthil Kumar6-May-08 2:54

S. Senthil Kumar

6-May-08 2:54

Hmm, it's tough then. You can actually create a Form on a different thread, but you must be careful and use Invoke/BeginInvoke when communicating between that form and the rest of the application.

Or you can simply show a form with a progress bar or some visual indicator (animated GIF?) on a different thread - this way, the user will know that the application hasn't hanged.

Regards
Senthil [MVP - Visual C#]
_____________________________
My Blog | My Articles | My Flickr | WinMacro

oscarderooij13-May-08 3:27

13-May-08 3:27

Hmmn, that wouldn't be the case..
We do have a progressbar, but it works only while not drawing.

In this part, when drawing.. even windows freezes... thats what I'm most worried about...
Do you know what can freez the application and windows like that?

Thanks again!
Oscar

Luc Pattyn5-May-08 7:19

5-May-08 7:19

Hi,

you should not try and run drawing code in a thread other than the main thread (aka
GUI thread). Instead you should use one or more additional threads to do the slow stuff
(computations, database access, network communication, etc) and from time to time
ask the main thread to adapt the GUI.

You can achieve this in many ways, including:
- explicit instances of the Thread class (good control of what runs when, at which
priority, etc)
- threads from the ThreadPool (less control);
- instances of BackgroundWorker class (it offers a ReportProgress method that
automatically runs on the main thread).

That is the theory. In practice, on top of the above, you'd better group the GUI updates
to avoid many small updates, instead group them (e.g. using a List) and have them execute
periodically. This results in:
- fewer thread switching, hence better performance;
- when organized correctly (e.g. Control.SuspendLayout), better performance and better
visual experience;
- possibly cleaner code.

Grouping updates can be done based on a counter, a timer, or whatever suits the application.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I dislike the black-and-white voting system on questions/answers. Dead | X|

oscarderooij6-May-08 2:42

6-May-08 2:42

Hi there Luc, thanks for the answer!

From what've learned I did know that I shouldn't run drawing code from a diferent thread. But the problem is that it is exacly the Drawing code that is freezing the whole program.

Since I can't draw from a diferent thread, I thought about running the whole form (everything about the form) in a diferent thread, as it was a diferent process (a subprogram from my project). This way I thought that I would be able to draw everything in this new thread, and it shouldn't freez the rest of the program.

Is that possible?

From what you posted I got a new idea to increase performance from the drawing function... I'll try to give some updates to the mainthread and see what happends.
I do not know much about controling comunication between threads... the max I know is how to use the CallBack function... this way when one ends, it tells the other.

But I don't know how to give signals from a thread to the main thread while both of them have still more things to do.

Actually, I found it weird that after reading everything I did I didn't find out how to do that.. maybe it is to advanced for me for now. Do you know any specific article that explains how to do this for Jrs?

Thanks again Luc!
Oscar

Luc Pattyn6-May-08 4:21

6-May-08 4:21

Hi Oscar,

oscarderooij wrote:
Is that possible?

Simply no. The only way to get a satisfactory behavior is by having all Controls (that
includes Forms) created and operated upon by the single main thread. Everything else
will fail either immediately or eventually. The reason is Controls are not thread-safe,
and all Controls are linked together one way or another (one Form parents and/or owns
another, a Form holds its Controls, etc) so there is no other way than to have a
single thread handle them all.

You really need to use some kind of thread to do computational and/or communication work,
and use a mechanism (such as InvokeRequired/Invoke) to send Control access jobs to the
main thread.

And you may need an interthread communication mechanism. There are classes for
signalling (e.g. AutoResetEvent and ManualResetEvent); and you can use whatever data
structures you choose, you probably need to lock them to prevent other threads to use
inconsistent data while updating (use the lock keyword and some lock object).

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I dislike the black-and-white voting system on questions/answers. Dead | X|

oscarderooij13-May-08 3:25

13-May-08 3:25

Thanks for the answer Luc,

I see... so there is no way to do that?
That's a problem.
Do you know a good article involving interthread communication?
I'll try looking for something here in codeproject now, but what I mean is if you know a specific good one for beginners or in any other way.

I'll learn how to use that someway.

Thanks again
Oscar

Luc Pattyn13-May-08 3:45

13-May-08 3:45

Hi Oscar,

No, I don't recall any exsceptional article on the subject, but that doesn't mean there are
none, it just says that's the kind of things I stopped reading long ago.

interthread communication isn't that hard. Basically the threads all can access your data,
so the one problem to avoid is having thread1 read some data while thread2 is modifying
that data, resulting in thread1 possibly having an inconsistent view of the data (parts
already changed, parts not yet updated).

The way to avoid this is typically is by locking the data whenever a consistent state is
needed and/or an "atomic update" has to be performed.

In C# the lock keyword is the key.

BTW: if you forget to apply locks, your program will typically run fine for a while,
then occasionally it will produce unexpected results.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I dislike the black-and-white voting system on questions/answers. Dead | X|

oscarderooij13-May-08 3:28

13-May-08 3:28

Oh, I forgot to tell something...

I don't think this is normal... but when my program is drawing everything, not only the program freezes, but windows too. And that's what I'm most worried about...

Do you know what kind of problems do this?
Thanks again
Oscar

Luc Pattyn13-May-08 3:40

13-May-08 3:40

Hi Oscar,

if your app is not involved in system stuff, then abusing threads for graphics stuff
may and will freeze the app, but not the system.

if your app is doing special things (say interprocess communication, networking, whatever)
and your way of drawing/painting is incorrect, resulting in a temporary or permanent app
freeze, then your handling of the special things, evn when implemented correctly, is likely
to suffer too, possibly leading to less than optimal system behavior.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

I dislike the black-and-white voting system on questions/answers. Dead | X|

oscarderooij15-May-08 7:45

Foreach property in myClass

15-May-08 7:45

I see... I'll look for the problem then.

Okey, so I'll learn about interthread communication then.

Thanks a lot for your patience and atention Luc!

Harvey Saayman5-May-08 3:57

Harvey Saayman

5-May-08 3:57

Hey guys

i just finished writing a class, all it is is a few 100 variables and their corresponding properties (only get accessors)

all the variables values are set in the constructor of the class and comes from a single sql query.

is there any way i can foreach through all the properties ive created for the class?

the idea is to do MessageBox.Show(PropertyName.ToString() + " --> " + PropertyValue.ToString()) so i can manually check that the right things are going into the right variables & gets accessed with the right properties

thanx

Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
think BIG and kick ASS

you.suck = (you.passion != Programming)

Colin Angus Mackay5-May-08 4:04

Colin Angus Mackay

5-May-08 4:04

Off the top of my head: You could use reflection to get the PropertyInfo for each of these from the Type, then iterate over the PropertyInfo[] array calling Invoke on the getter.

Upcoming FREE developer events:
* Developer Day Scotland

Recent blog posts:
* Introduction to LINQ to XML (Part 1) - (Part 2)

My website | Blog

S. Senthil Kumar5-May-08 4:06

S. Senthil Kumar

5-May-08 4:06

Reflection is your friend.

foreach (PropertyInfo propertyInfo in this.GetType().GetProperties())
{
   Console.WriteLine(propertyInfo.Name + "=" + propertyInfo.GetValue(this, null));
}

You can use the other overload for GetProperties to get non-public and non-static properties as well.

That said, I'd be worried if I had hundreds of properties in a class.

Regards
Senthil [MVP - Visual C#]
_____________________________
My Blog | My Articles | My Flickr | WinMacro

Harvey Saayman5-May-08 4:12

Harvey Saayman

5-May-08 4:12

thanx, ill try it quickly

S. Senthil Kumar wrote:
I'd be worried if I had hundreds of properties in a class.

i know it sounds weird, the class contains all the parameters for a shift(im developing a time & attendance package) and there really are 100's of variables that make up a "shift" because certain roundings must happen in certain intervals before a shift starts and ends and the same for coming late and leaving early.... its quite a complicated industry

anywho... thanx for the help

Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
think BIG and kick ASS

you.suck = (you.passion != Programming)

carbon_golem5-May-08 5:01

carbon_golem

5-May-08 5:01

I would venture to suggest that if there are that many parameters, you could turn the properties into a ShiftParameter and stuff them into a collection, and add what's needed. With the custom class, you can add validation parameter by parameter, and I think it would be easier to maintain and extend.

Scott P

"Run for your life from any man who tells you that money is evil. That sentence is the leper's bell of an approaching looter." --Ayn Rand

Nouman Bhatti5-May-08 4:07

Nouman Bhatti

5-May-08 4:07

If it is possible than it will be only through Reflection bcz you want to get class information at the runtime

Yevgen Lisovenko5-May-08 4:07

Yevgen Lisovenko

5-May-08 4:07

Use reflection