Need advice on how to "finish" a form program

[Ravenn]

hi:)
i'm writing a windows form program that controls 4 stepper motors, using visual studio express 2010, c++
i'm using a for loop that has to cycle for up to 1200 times. it works well enough but it's kinda slow and, when it's connected to my hardware and given more than 300...400 loops, it shows "not responding" until it reaches the end of the cycle. during this, it moves much faster. That speed would be allot better for my application, but i dunno how to control it.

i'd like to know how to make my form program work properly when i simply launch the exe that VStudio creates in the debug folder (as far as i know, that's the finished "product" i need:) ), if i'm supposed to somehow set some sort of priority for it that windows will handle. I don't know if i should used threads, because i don't have several simultaneously running parts of my program, just that loop, and since i never used them, i'm not sure what else they do...

I don't have experience with form progs so i'd just like to be pointed in the right direction. What could cause the freeze and increase in speed and how do i make a form program properly "launchable" under Windows so that it doesn't freeze and it runs fast.

[Narue]

You need to do the work in a separate thread from your UI. That way the UI is still responsive while long running tasks are being performed in the background. You don't have to make the background task faster, just alter users' perception of application performance by avoiding the "Not Responding" message.

As for the "finished product", if you're planning on distributing the program to other machines, an installer package ( NSIS or Inno Setup , for example) would be a good idea. Otherwise you'll need to be very careful to distribute all of the dependencies.

[Ravenn]

Thanks:) i'm looking at those installers right now... as for speed, the hardware i control depends on the speed of the loop

[jonsca]

I'm assuming that you're working in C++/CLI since you are doing WinForms. Check out the BackgroundWorker , as I believe that's the most straightforward way of getting a separate thread (and I believe it was designed for exactly this purpose, i.e. for separating the GUI and the meat of the code).

Just make sure you're not running life support systems or nuclear missile silos with these motors. If that's the case, you'd probably want something embedded.