Well you got a really big callback. Anyway one thing I see is
int CVICALLBACK ACDCswitch (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
int measKnob, srcKnob;
Polling = FALSE;
switch (event)
{
case EVENT_COMMIT:
Here you are setting Polling to FALSE before looking at your event. Remember
this callback will get called for any event for this control, better would
be to set polling to false on the event that you want, which will we in one
of the case statements.
Also do you want to make measurements as fast as possible. I will have some
delay in between. What I do is use my own delay function where I use timer()
to delay and call ProcessSystemEvents in between like:
void Wait(double NumOfSeconds)
{
double t0;
double t1;
t0 = Timer();
t1 = Timer();
while (((t1-t0) < NumOfSeconds) && Test_Running) {
ProcessSystemEvents();
t1 = Timer();
}
}
What would I do is use Timer to do your polling every so often. You can even
use AsyncTimer for that. Based on what user selects, you do different
measurements.
There is no error checking for any of your instrumentation stuff.
vishi
"Daynesh" wrote in message
news:506500000008000000DF910000-1042324653000@exchange.ni.com...
> I am experiencing problems with my GUI that I cannot seem to
> consistantly reproduce. I have attached a .uir file and a .c file
> that includes just a few control callback functions.
>
> Summary of GUI: GUI acts as a DMM continually taking measurements from
> a connector located on a DMM-PCI card. When the DMM GUI is launched,
> no callback function is initially called. When the user changes the
> Measurement knob position to say 2Ohms, the DMM reads in a resistance
> value from the connector on the DMM PCI-card and displays the value
> read on the textbox labeled, OUTPUTSCREEN. The DMM continues to take
> new resistance measurements (by way of a do-while loop...see source
> code). This infinite resistance measuring ends when the user changes
> the position of the knob (or does anything else with any other control
> on the GUI). It does this via a ProcessSystemEvents call within the
> do-while loop. It then calls the Control Callback function and starts
> some other DMM measuring.
>
> Problem: Every now and then, I will be running the .exe and when I
> try to take a DMM measurement, the GUI locks up and does not allow me
> click on any control after that. I can't even exit out of the GUI. I
> have to ctrl-alt-del to get out of the executable. Sometimes I get
> the DMM to continually take, say resistance measurements. Then while
> the DMM is displaying new resistance values every second, I try to
> change the Measurement knob to say, capacitance, and the minute I
> click on the mouse once (without releasing the left mouse button), the
> GUI locks up. Now I was able to determine that the problem may be
> related to the way I am using the ProcessSystemEvents() function.
> Refer to my MeasurementFunction callback in the attached .c file.
> Lets say the GUI locks up when the knob is in the OFF position.
> Within the do-while loop that falls under the 'if (meas == 0)'
> statement (line 43), when ProcessSystemEvents is called, it never sees
> an EVENT_COMMIT (which is understandable being that the GUI locks up
> before the mouse button is released). But this problem should be
> avoided by setting the 'Polling' variable to FALSE before the
> switch-case statement is called. And lets say clicking on the knob
> during execution does call the MeasurementFunction callback (which it
> should & probably is), before the GUI locks up and before the mouse
> button is released, 'Polling' is set to FALSE, the switch-case
> statement determines that the Event was not an EVENT_COMMIT and just
> 'break' out of the switch-case, end the callback function call and
> return to the point immediately after the execution of
> ProcessSystemEvents. What should then happen is the do-while loop
> should end because 'Polling' is now FALSE. But when the GUI locks up,
> somehow 'Polling' is still TRUE and so is not able to break out of the
> do-while loop and ProcessSystemEvents is never properly detecting any
> kind of Event after the lock-up.
>
> Also, I have come to the realization that the way I am using
> ProcessSystemEvents can eventually overflow the stack. Fortunately,
> this problem has never occurred and I will eventually address this
> problem.
>
> Please assist. If you need any more info you can email me.
>
>
> Daynesh