Application lags, until second Instance is started - AND no lagging on another machine...

Question

Hey, it's me again:
The last days I started to get along with LabWindows quite well, and my program grew very fast, but today I found a probleme, I do not really know how to handle.
When I compile my program (both in "debug" and "release"-mode), and start it, it lags quite a lot, but the another version, I still had from friday and did NOT lag that day, started to lag too. So there must be any problem with maybe the configuration or whatever.
But the weirdest thing:
When I first start one Version (does not matter which one), and than afterwards start another Instance of it, or a complete other Version (maybe one Version of Friday, and on I just compiled), the second Application (which lags when being started alone), does NOT lag at all.
In addition to that, all Versions do NOT lag, when I start them on a little netbook, where they're supposed to be used anyway.
Sumarizing:
1 Instance --> lagging
2 Instances --> first lags, second doesn't
This whole thing is very frustrating
I hope, some of you may know what to do!
Greetings from Lübeck
Mathias

Answer 1

MacMatze:
Glad you found the problem.  You don't need to be embarrassed by it, but you should learn from it.  It sounds like you need to do some error handling, and should probably do some status reporting.  Here are a couple of suggestions.
1. To troubleshoot a "lagging" problem, you could single-step through your code to see which statement takes longer than you expect.
2. If the problem was that a power supply was unplugged, it was still unplugged when you started your second instance of the program.  I'd guess you didn't see the lag on the second instance because one or more errors were generated because some resource (maybe like a COM port) was already tied up by the first instance.  Since you didn't mention getting error when you started your second instance, I'd guess that you are ignoring errors that you should be handling.  Many functions indicate errors in their return variables.  Review your code for functions whose return variables you are ignoring.  Handle them as needed, even if it's just with a dialog box.
3. "Of course" your supply will always be plugged in?  Have you heard of Murphy's Law?  If it was unplugged for you, it might be unplugged for another user.  Or the fuse may blow or the power supply may die.  You should find a way to detect and report conditions like that, so your user isn't wondering why the program isn't starting.
4. If you have multiple steps in your program or hardware initialization, you could put up a status bar with messages indicating the current operation, so if the program appears to hang, at least the user has some idea on what the program is trying to do.