cross thread operation not valid, when closing a windows form

[But_Im_a_Lady]

Thanks - will do Janet

Lady Programmers are a rare breed!

[But_Im_a_Lady]

Thanks - will look at this & try & get it to work. Janet

Lady Programmers are a rare breed!

[But_Im_a_Lady]

Just to prove your theory I commented out all references to 'faxing' (this was the other thread in my form) & I still get this error. So now I am confused:confused:

Lady Programmers are a rare breed!

[But_Im_a_Lady]

My first step was to comment out all references to 'faxing' (this was the other thread in my form) and I still get this error. So now I am confused:confused: Janet

Lady Programmers are a rare breed!

[Henry Minute]

The only thing that makes any sense is as 12Code said in his OP. Somehow the 'faxing' thread is getting started, and then causes the error when you close the app. What sort of threading are you using? Is it a BackgroundWorker, or are you creating it in code? Whichever type, one way might be to handle the FormClosing event of your main form and close/de-activate the thread there.

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

[0x3c0]

What about the if-clause? Doesn't that access chkShowSparesMatrix?

[But_Im_a_Lady]

I am using 'System.Threading', the code is below:-

private void FaxEngineersRequest()
{
try
{
//SendZetaFax sendZetaFax = new SendZetaFax ();
//sendZetaFax.FaxBody = _processingModule.CreateEngineerCallSheet ( _callNumber ).ToString ();
//sendZetaFax.FaxNumber = usrAddressDetailsEngineer.Fax;
//sendZetaFax.RecipientName = usrAddressDetailsEngineer.Contact;
//sendZetaFax.From = _sysCNDR.Name;

            ////Since the processing for Zeta fax can be v.slow - do processing on a separate thread.
            //Thread thread = new Thread ( new ThreadStart ( sendZetaFax.SendFaxMessage ) );
            //thread.Start ();
        }
        catch (Exception ex)
        {
            \_commonValidation.DisplayErrorGracefully ( ex );
        }
    }

As you can see I have commented this part of the code out - so it will never run, but I still get the cross thread operation not valid error. <blockquote class="FQ"><div class="FQA">Henry Minute wrote:</div>Whichever type, one way might be to handle the FormClosing event of your main form and close/de-activate the thread there. </blockquote> Not quite sure how / if / why I need to do this :confused: Janet

Lady Programmers are a rare breed!

[But_Im_a_Lady]

Yeah I suppose it does. Even if I comment out the single method which uses System.Threading to send a fax (this method isn't always called in code anyway), I still get the 'cross threading operation not valid error message. I have no idea why:confused:

Lady Programmers are a rare breed!

[Henry Minute]

If your 'faxing' thread does not run, and it certainly shouldn't from the code you posted, then there has to be another thread running to cause the exception. If you don't know about this thread, you obviously cannot close it in the FormClosing handler. You might however put a break point there and use the debugger to search for the 'Thread With No Name'. I would suggest Googling for 'Debugging Threads C#' for methods to do this. As always, come back if no joy.

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

[Luc Pattyn]

Hi, here is my standard reply on cross-thread problems, I hope it helps: Controls are not thread-safe, hence they should be touched (that is: their methods or properties called) only by the thread that created them, which normally is the main thread (aka GUI thread). Creating some controls on a different thread is unlikely to be successful, since all Controls get linked somehow: they reside on Forms, Forms are related to each other (by Parent, by Z-Order, etc), so normally all are created on a single thread. If you violate the “don’t touch Controls from another thread” rule and are running .NET version 2.0 or above you will get an InvalidOperationException (“Cross-thread operation not valid”), which should be remedied by changing the code. Do not set Control.CheckForIllegalCrossThreadCalls false, since that does hide the exception but does not cure the fundamental flaw in your code, so it just postpones the moment of failure, which typically will show as a non-responsive and possibly badly painted GUI. Here are some ways to get another thread: - explicitly launching a Thread instance - exclicitly delegating some work to a ThreadPool thread - using a BackgroundWorker; a BGW is a separate thread with the advantage that two of its events (ProgressChanged and RunWorkerCompleted) execute on the GUI thread; however the bulk of the work normally is handled in the DoWork handler which runs on a distinct thread. - using timers other than System.Windows.Forms.Timer; the Forms timer ticks on the GUI thread, all other use different threads to handle the periodic event; - using asynchronous input/output, such as the DataReceived event of the SerialPort class Any of these touching a single method or property of a Control is sufficient to create havoc; there are 5 exceptions: - the InvokeRequired property - the Invoke, BeginInvoke, EndInvoke and CreateGraphics methods (the latter only if the handle for the control has already been created). If there is a need to touch the Control from another thread, one must use an Invoke pattern, which basically looks like this:

public void SetText(string text) {
if (myControl.InvokeRequired) {
// this runs on the foreign thread and causes the
// invocation of this same method on the GUI thread
myControl.Invoke(new Action< string >(SetText),
new object[] {text});
} else {
// this runs on the GUI thread only
myControl.Text=text;
}
}

:)

Luc Pat

[But_Im_a_Lady]

For completeness of this message - I have now fixed my problem. I made a STUPID :doh: mistake... Rushing to finish the project I had put Close() inside the formclosing event!!! Won't be doing that again in a hurry :)

Lady Programmers are a rare breed!