Re: Threading - C# Discussion Boards

Member 9629-Mar-07 7:42

29-Mar-07 7:42

Are you directly creating a thread then directly aborting it? If so I recommend you have a look at this instead:

http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx[^]

Using a Backgroundworker is safe, easy and allows for built in methods to cancel the operation in progress.

HexaDeveloper29-Mar-07 9:50

29-Mar-07 9:50

hi,

no i click a button that create thread to do some thing
that is still working until i click another button that is supposed to abort it but it is not working

Generator

Member 9629-Mar-07 10:01

29-Mar-07 10:01

The page I linked you to contains all the information you need to accomplish that. After reading it and trying it out if you still have a question reply to this message.

HexaDeveloper29-Mar-07 11:12

29-Mar-07 11:12

thanx it seems to be my goal but there is a problem

when run a run time error occurs

"Cross thread operation not valid: Control 'my_form name'
accessed from thread other than the thread it was created on"

!!

Generator

Member 9629-Mar-07 11:28

29-Mar-07 11:28

You can not access any controls on your form from a thread you create.

That is the whole point of the backgroundworker object, it has a set of events that allow you to update controls on your form and to respond to and initiate events such as reporting progress or cancelling an operation in progress.

If you have read that article you will note that UI controls are only accessed in the events of the backgroundworker object, not in the work that is performed by the new thread.

Generally speaking, the code called in the "DoWork" event of BackGroundWorkder must never attempt to access any UI objects.

The controls on your form are created in the main UI thread when the program starts. They are not thread safe, you will either get an error or a crash if you attempt to access them from another thread.

HexaDeveloper30-Mar-07 9:57

30-Mar-07 9:57

Hi,
ok i use in the do_work method i made called movePacket();
this method call Invalidate(); in it so
Is this that may be made this conflict and if it
what can i do

thanx to help me

Generator

Member 9630-Mar-07 10:54

30-Mar-07 10:54

I don't think you are understanding the basic problem: You can not make any GUI related calls within the do work method. Calling Invalidate is a GUI method.

You should not need to at all. Any update of the GUI should take place only within the ProgressChanged event. Please look at the sample again, in fact I recommend you copy and paste it into a new project and experiment with it until you understand it. If you are calling Invalidate in the dowork method you are accessing the GUI from a different thread than it is working in which will lead to errors and possibly crashes.

HexaDeveloper1-Apr-07 2:36

1-Apr-07 2:36

Hi John,

sorry for a lot of questions but i donot understand it really Cry | :((

i made a new project and run this example & made trace
but i miss understand it (i cannot understand its mechansim)
but i tried so i could solve the problem and it is acceptable (so 2 questions)

1- I noticed from examples that reportProgress used always with progressBar but i donot have one and i put in it the Invalidate Method so

What can i do with the percent-> ReportProgress(percentage);

2- when i make Dispose for BackgroundWorker after Cancel
Error ocurred and tell me that thread does not finish its work

Generator

Member 961-Apr-07 6:35

1-Apr-07 6:35

1) You don't have to use this with a progressbar, even if it's just a spinner cursor or a text box that get's updated but *somehow* you are reporting to the end user that something is still happening right? In one app I use a progress bar, but I also use a text box to report the stage of a multi stage operation and in the backgroundworkder ReportProgress method I put the string of text describing the state in the UserState object parameter. Then in my UI's progresschanged event I both update the progressbar and the text box with the UserState string.

Why do you need to call invalidate, you can just update whatever UI objects you are using to report progress in the reportprogress event. I can't think of any reason to call Invalidate.

If you don't want to report anything to the user and are just using the backgroundworkder to spawn a thread to do something behind the scenes there is no need to call reportprogress or handle the progresschanged event (though it's still useful in a non UI situation in case you want to detect if it's stalled for some reason even just in code)

2) I've never found a need to call Dispose on the backgroundworker object so I can't speak to that but the error seems to indicate, you are calling it too early.

A lot of what you seem to be having problems with sounds like it stems from your earlier attempts to manually create threads and doesn't apply to the backgroundworker method at all. It seems like you are overthinking this and putting too much extra code in that you don't actually need. Without knowing the exact details I can't say for sure, but that's what it sounds like.

HexaDeveloper1-Apr-07 8:27

1-Apr-07 8:27

hi,
actually from what u wrote i answer about three things

1- i use invalidate as i draw one rectangle at a moment
so i invalidate the form to draw the new location of the rectangle and remove the last(all drawing in OnPaint())

2- actually i admitt that my code is terrible (my friends said: good mind but random coding,no anaylsis)
so
i try to release some of memory
(my program seems to have memory leak) of what i donot need but as i am not completely understand BackGroundWorker so may be i use it in wrong space

3- i donot want to invalidate the whole frame just part
so i use invalidate as it is taking one argument of area of invalidation but update not taking parameters

thanx

Generator

Member 961-Apr-07 9:50

1-Apr-07 9:50

Hi I don't know a lot about graphics to be honest, what I recommend is that you try a test where you do *not* use a separate thread but keep all the other code identical and see if you still have a memory or resource leak. I suspect you will and threading is not relevant to the leak issue at all.

Or alternatively keep the background workder and try a different UI (just for experimenting) get rid of the box drawing, try something simpler first like updating some text in a text box instead. That might show you where your problems are with this.

Disposing of the thread isn't really related to recoving resources that are consumed by code that runs in that thread. If something inside the thread is leaking it must be fixed inside the thread, not by disposing of the entire thread.

All in all the best way to approach a problem like this is to break it into it's separate components, i.e. break apart the threading from the UI work and diagnose it that way. Often that will either lead to the solution or cause a different way of looking at it or at the very least a better understanding of how the backgroundworker works.

HexaDeveloper1-Apr-07 12:06

1-Apr-07 12:06

Hi john ,
i think i got the reason of memory leak
when i draw one time at a moment i make a rectangle by
e.Graphics.DrawRectangle(Brushes.RED,sourcePoint,4,4);
so it must be in memory and with a lot of drawing
consuming memory will go to be a disaster

so if i make this rectangle as object and change its location every time(means one object with different locations)

do u think the old location will take a space in memory !! or it will be deleted automatically

thanx

Generator

Member 961-Apr-07 12:11