Using toolStripProgressBar1 inside a Thread

Original Poster: I have xxx, then do yyy then zzz happens. Here's my code ...

Ok. You know what you have.
What you don't have is a question. Nobody here knows why you posted this since you haven't asked anything. You could be asking "What does the error mean?", you could be asking "Which control is it talking about?", you could be asking "Will someone do my debugging for me?"

I recommend you read the FAQ about How to ask a good question so the volunteers will be able to help you.

Commonly this comes from creating a new thread, that then tries to make a change to control on form that was made from the primary thread of the application. For example, your main form has a label or textbox (or progressbar in your case) where you are putting up status updates... and your worker thread is trying to directly write those updates directly to the control. You can't do that. You would need the worker thread to raise an event that your other thread would subscribe to, then react to.

This might help. Two forms, two classes, two threads... its all basically the same thing.

Original Poster: How do I get my Form2 to react to something on my Form1?
How do I make my Form1 control something on my Form2?

Although you can have Form1 directly access items on Form2 it isn't the recommended way to go. It ties the two forms tightly to each other. If a change is made in Form2 such as removing one of the controls, then code in Form1 breaks.
It is better to Form1 raise an event, and have Form2 contain its own code for how to react to this. This places responsibility for Form2 within Form2, and Form1 within Form1.
It keeps Form1 blissfully ignorant of Form2 - and a logging component - and a progress component, and a dozen other little black boxes that can be subscribed to events in Form1, all without Form1 being made responsible for directly affecting controls other than itself.
Events tutorial (including Form to Form which is the same as class to class)
This tutorial for a cash register does exactly that: It makes a virtual numeric keyboard.

Bad: Directly accessing controls of one class/form from another. Good: Use a property to get such information It's a subtle but important difference as your applications become more complex. Using properties means your target class/form (Form2) can be changed and updated a thousand different ways yet won't negatively impact the classes that are reading from it. If you change the name of a control for example: It won't break references in all your other classes. If your target form evolves where it needs to do 10 things when it is turned on, then the responsibility stays within Form2, and that burden is not put on Form1 and a dozen other forms that might be using Form2. The goal is to compartimentalize the work so that Form2 is responsiblity SOLELY for Form2. From1 should only have to say "Turn on" or "Turn Off"

Form2 Now when Form1 tells Form2 to turn on, Form2 will check a box, make an entire panel visible, change its Status label to say 'On' and enable a Run Now button.

My question is;
How use toolStripProgressBar1 inside a Thread?
Because I recive the following error in this line:
Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on.

Starting the Thread:

Gabiel: How use toolStripProgressBar1 inside a Thread?

If the toolStripProgressBar was made from a different thread (the main thread that made the form) then you don't. That's what the error message is telling you. One thread does not have the ability to affect controls made from a different thread. Your progressbar was made by the thread that build the form. Your ReadNPI method is happening on a different thread.

Your ReadNPI thread Processo needs to raise an event, and your main GUI thread needs to react to that event.

You have to use Form's Invoke()-method, this would marshal your operation to the GUI-thread. Because it's not allowed, to do something in your GUI from another thread, which the GUI (Control-object) was created.

You have to do this everytime you set a control's property or call it's method.

E.g. instead of
you'd better use (if your'e using .net 3.5)

Invoke() is a synchronous (blocking) call, if you want to do a non-blocking call, you could use Control's BeginInvoke()-method (has the same signature as Invoke() )

Yeah, you can use invoke... but I would avoid it. It tightly ties your thread/class to the GUI. If you change the GUI then you break the other threads. It really violates the whole idea that each part of your application should be a self-contained little black box that does its own job and nobody else's.

If you have your thread raise an event... You could have 10 different classes subscribe to it. Or none. One could update the progress bar, one could add a log entry, one could add the file to a processing queue, one could open another form asking for feedback on how the user liked the system....

The thread should only be responsible for what the thread does - not the GUI user experience.

@tlhintoq
Yes, it's true, the Thread's operations shouldn't be responsible for how the GUI should handle this.
But in the source-code the Thread is private within the Form, so there won't be problems in case of code reusage or anything else.
If the threaded operation would be done outside (other class than) the form-class, it wouldn't be nice to do this Invoke.

But at least you'd nee to do invocation anyway, because if you'd use an event in the Tread, your event-handler would be called from the Thread's context and invocation will be necessary to do GUI things.
Now there are different approaches, how to handle it, the simplest would be
(it's conceptual, I don't know, if it's working that way)
the other approach would be marshalling in your threaded context
e.g.