views:

313

answers:

6

I have a college assignment due quite soon, and I need to be able to call a C++ dll that takes a long time (possibly infinte, it relies on user input)to execute. Im calling this through VB. My VB GUI freezes up when this happens, and I would like to keep the GUI responsive, so that the user can stop this possibly infinte loop.

Can anyone suggest the best/fastest way of doing this?

A bit of background, the C++ is trying to keep score on a snooker table using a webcam, and while the VB scoreboard updates easily, I would like to script it so that the analysis is almost continuous, while still allowing the user to interact. Currently the project requires the user to press a button to start the shot analysis, but it would be preferable if the program scripted itself. I have only realised this problem now and the deadline is very soon.

Update: Our lecturer suggested an option to solve the problem, but it would appear that most options here and the one he suggested will not work for us as the processing time required for the webcam image capture is too great to handle due to hardware constraints. Thanks for taking the time to help, it was much appreciated!

+2  A: 

The best way to handle threading in VB.NET is via the System.Threading namespace.

You might also look into Application.DoEvents()

Mark Biek
Although Application.DoEvent() has nothing to do with threading.
erikkallen
I never said it did :)
Mark Biek
He can't call Application.DoEvents() from his external C++ dll though, can he? I think simple threading is the answer here.
configurator
+1  A: 

Try the system.Threading as Mark said, also try looking at Background Worker Process which is a bit simpler in VB.NET. Readup here

Saif Khan
A: 

Just as an alternative, you could have your C++ actually processing in the background all the time. When called from VB, it would just be retrieving data from it or sending it a command (start, quit, ???) all of which would return instantly.

This could also give you more reliability since C++ would never miss video frames while VB was collecting the garbage or doing the dishes or whatever VB does in the background--C++ is going to let you be closer to a real time system.

RE: the comment about how.

What I'd probably do is have my VB programs send "Messages" to the C++ (As I said). A message is just a way to think of a function/method call--but generally they return quickly.

The "Start" message would tell the C++ code to start it's thread running and return. This is a Linux C++ thread howto, I'm not sure if you need to do something different in windows (I'd hope not, but I haven't used C++ as my main dev. language in decades).

If that doesn't work, just google "C++ Threads"

Sending a "Stop" message would stop the thread (and probably free resources).

A "Get Data" call would go to the location that the C++ thread used to store data, grab it and return.

Sorry to be so general, I'm pretty heavily Java these days.

Bill K
This seems like a good option. How would I go about having the C++ running in the background all the time? I was trying to use a do until loop in VB to keep downtime to a minimum, but this seems like a better option.
A: 

Ive had a look at the systemthreading and background worker process, but Im worried about the code I have already written. Should I have the UI and the analysis running in two seperate threads from the start or can I just call the analysis in a thread from the VB when its required?

Edit the question, unless you're actually answering it.
Arafangion
+1  A: 

I would definitely use the Background Worker process. You can drag it onto your form and use the DoWork sub routine to actually do the work that is freezing your GUI thread. You can also use the ReportProgress event to actually provide progress back to your form.

As for your question regarding two separate threads, If both steps take a long time to complete I would run them in the same thread one after the other.

The one thing that could bite you with using the thread is cross-threading. In the context of your problem this means not having your second thread update form controls.

A really good resource for how to implement this code along with dealing with cross-threading is this PDF.

I also should point out that if you are using .net 1.0/1.1 you can still do the multi-threading, but don't have the luxary of having a background worker control. You'd just have to create a new thread from the System.Threading Namespace.

Rob Haupt
A: 

I'm surprised nobody has suggested using a BackgroundWorker yet.

configurator