I see your point.

A little background might clarify some things for both of us. This application is being used to control a vision inspection system. The UI has three displays for each part inspected and numerous text boxes and labels for counts and pass/fail indicators. Because this system will be implemented on the production floor, it needs to be assumed that it will inspect parts indefinitely (or until the user terminates the inspection). This is what created my need for threading, running the infinite inspection loop while allowing the user the control to kill it when needed. As you can imagine, the interface has to update for every part.

I may just be being overly cautious, but I want to make sure that the worker thread is not updating variables that the invoked thread is using to update controls on the UI (the main danger with threading, right?).

Time is important as I have only about four seconds between parts, but it is not the reason for threading. The sleep command is a quick fix, but I'd rather have more robust programming that doesn't use a subjective number as the milliseconds parameter is.

It's entirely possible that I'm missing something in threading philosophy. Feel free to correct me on any of this.

Jason

Sounds like an interesting project.

Is there something that triggers the start of a single inspection? It seems like this would simplify things greatly. From what I understand, you are continuously looping through this logic and, thus, possible running extra passes that aren't needed. I would imagine that you would do everything possible to NOT have anything that would stop code execution for something running on a production line.

-Peter