LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

GUI control callback freezes executable & maybe related to ProcessSystemEvents call

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
Download All
0 Kudos
Message 1 of 4
(2,964 Views)
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
0 Kudos
Message 2 of 4
(2,963 Views)
In all my instances of seeing this problem with the GUI locking up, I have not experienced it after clicking on the ACDC_SWITCH control. The problem arises when the user clicks on the MEASUREMENT_KNOB control or the SOURCE_KNOB control. And this, I believe, has to do with the call to ProcessSystemEvents() within the callback functions associated with the aforementioned controls.

The problem seems to occur as soon the the left-mouse button is clicked (without releasing) over the MEASUREMENT_KNOB. As soon as this happens the GUI locks up and no longer allows the user to click on any control or even properly exiting out of the GUI. But the DMM is still taking measurements (depending on what position the MEASUREMENT_KNOB was previously in). This is indicated by the DMM OUTPUTSCREEN continually being updated after every measurement read. Now analyzing the callback function for MEASUREMENT_KNOB, one can see that if the DMM is still taking measurements but just not allowing any user interaction, execution of the program seems to be stuck within a do-while loop (lines 179 to 207 for 2-wire Resistance measurements as an example). This only occurs if the Posting variable never changes value back to FALSE (which theoretically should be done immediately after a callback function is called...Because I am usually clicking on the same MeasurementFunction callback when the problem occurs, Polling is immediately set to FALSE at the beginning of the MeasurementFunction--line 20). This problem only leads me to believe that when ProcessSystemEvents is called the first time within the do-while loop, it returns back to the do-while loop, locks out any future events from being processed, and continues the execution of the do-while loop.

Thank you for pointing out about my lack of error checking. I will add error-checking code in the near future. (Something I completely overlooked.) But as far as my immediate problem, I have hit a brick wall. With respect to your suggestion about creating my own Wait function, I don't believe that the Delay() after the ProcessSystemEvents() call is absolutely necessary. I had only recently added the Delay() call in the code. Are you suggesting that the reason why ProcessSystemEvents no longer processes any future events once lock-up begins is because there needs to be a Delay() of some kind immediately after the ProcessSystemEvents() call?
0 Kudos
Message 3 of 4
(2,964 Views)
Well let us say you have something like this

while()
{
SomeFunction()
ProcessSystemEvents()
}

Assuming your SomeFunction takes 5mins to execute, then you are hung up for
5mins. You are only looking for events in GUI queue, when
ProcessSystemEvents is called. Now if your SomeFunction was taking only
100msec or something, you are ok, as ProcessSystemEvents gets called often
so GUI is responsive to the user.

Never had problems with calls to ProcessSystemEvents in callbacks. Tried
running your program but can't as I don't have all the files needed. You
need to post the code without instrument calls. Also in measurement function
callback, you have

// Global Variable
Polling = FALSE;

switch (event)
{
case EVENT_COMMIT:


Now when you click on MEASUREMENT_KNOB and you still haven't released it a
callback gets called whether you handle it, it is up to you, so Polling =
FALSE; right at that moment. I think you want to do things when COMMIT event
is called (when user released the mouse button). You have another Polling =
false for COMMIT event, so why the first statement.


vishi


"Daynesh" wrote in message
news:50650000000500000070040100-1042324653000@exchange.ni.com...
> In all my instances of seeing this problem with the GUI locking up, I
> have not experienced it after clicking on the ACDC_SWITCH control.
> The problem arises when the user clicks on the MEASUREMENT_KNOB
> control or the SOURCE_KNOB control. And this, I believe, has to do
> with the call to ProcessSystemEvents() within the callback functions
> associated with the aforementioned controls.
>
> The problem seems to occur as soon the the left-mouse button is
> clicked (without releasing) over the MEASUREMENT_KNOB. As soon as
> this happens the GUI locks up and no longer allows the user to click
> on any control or even properly exiting out of the GUI. But the DMM
> is still taking measurements (depending on what position the
> MEASUREMENT_KNOB was previously in). This is indicated by the DMM
> OUTPUTSCREEN continually being updated after every measurement read.
> Now analyzing the callback function for MEASUREMENT_KNOB, one can see
> that if the DMM is still taking measurements but just not allowing any
> user interaction, execution of the program seems to be stuck within a
> do-while loop (lines 179 to 207 for 2-wire Resistance measurements as
> an example). This only occurs if the Posting variable never changes
> value back to FALSE (which theoretically should be done immediately
> after a callback function is called...Because I am usually clicking on
> the same MeasurementFunction callback when the problem occurs, Polling
> is immediately set to FALSE at the beginning of the
> MeasurementFunction--line 20). This problem only leads me to believe
> that when ProcessSystemEvents is called the first time within the
> do-while loop, it returns back to the do-while loop, locks out any
> future events from being processed, and continues the execution of the
> do-while loop.
>
> Thank you for pointing out about my lack of error checking. I will
> add error-checking code in the near future. (Something I completely
> overlooked.) But as far as my immediate problem, I have hit a brick
> wall. With respect to your suggestion about creating my own Wait
> function, I don't believe that the Delay() after the
> ProcessSystemEvents() call is absolutely necessary. I had only
> recently added the Delay() call in the code. Are you suggesting that
> the reason why ProcessSystemEvents no longer processes any future
> events once lock-up begins is because there needs to be a Delay() of
> some kind immediately after the ProcessSystemEvents() call?
0 Kudos
Message 4 of 4
(2,964 Views)