CVI 2010 missing EVENT_VAL_CHANGED

[Mark_D]

We are using LabWindows 2010 SP1 on Windows 7 and Windows 10.  Our application was upgraded from LabWindows 7.  Never had this problem in LabWindows 7.

We have are having a problem that the EVENT_VAL_CHANGED is not being sent to our callbacks after a ring selection has been changed.  This happens in release mode and when debugging the program in the IDE.  This happens with more than one ring control but is somewhat random when it will popup (problem happens 5% of the time).

Ring control mode is Hot in the UIR.  No SetCtrlAttribute calls were made on the ring control.

Steps:

1) Change ring selection from default selection, no callback

2) Change the ring selection back to the default selection, no callback

3) Change ring selection from default selection, no callback

4) Change the ring selection back to the selection value, no callback

5) Change ring value from default value, the program does get a callback with EVENT_VAL_CHANGED

What could cause the event to be lost?

[Ian.W]

Some things come to mind that might help:

• Have you tried to operate the panel within the UI editor, and watch the events that are generated? (There is a icon with red & green dots in the upper left corner of the UI editor for the Operate Tool.)
• Do you have any multi-threading going on? (Someone else might be able to help there.)
• Have you quadruple checked your callback for erroneous brace matching? (Place a cursor in the key spot and press Ctrl-B repeatedly to see the matching -- in an expanding scope with each press of Ctrl-B.)

Hope this helps!

[Mark_D]

Yes, the UI editor shows EVENT_VAL_CHANGED when I change the value in test mode.

We do not have any multi threading.

Braces match.

Thing is, it works fine 95% of the time.  That 5% is doesn't is a big problem.  I run the program in the debugger with a break point on GetCtrlAttribute and I change the value of the control.  Sometimes I change the value and I don't get the event.  Happens outside the debugger too.

This is the code:

int CVICALLBACK GetPath(int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
    int index;
    char label[400];

    switch(event)
    {
    case EVENT_VAL_CHANGED:

        GetCtrlAttribute(panel, PROG_GETPATH, ATTR_CTRL_INDEX, &index);
        GetLabelFromIndex(panel, PROG_GETPATH, index, label);

        SetCtrlVal(panel, PROG_NEWPATH, label);
        break;
    }

    return(0);
}

[Ian.W]

Hmm. Could it be an accidental, rapid change in the control back and forth but ending on the desired and expected selection?  The EVENT_VAL_CHANGED in that case could be pretty touchy and fire 2 or 3 times. Or maybe you have another panel or control inadvertently firing it - that might warrant checking the panel and the control coming back in the callback to make sure it is what you expect. 

Perhaps DebugPrintf to log each time the code is reached to make sure you always have the expected values. That would allow you to operate it extensively and scan the listing for anomalies.

All long shots, I admit. 😞

[Mark_D]

Thanks for your reply.

We aren't changing the control rapidly.  It won't work on the first change either.

We have controls on other panels that have the same problem -> they are ring controls as well.

We don't get the EVENT_VAL_CHANGED so the code isn't being reached, the debug print wouldn't work.

These same controls worked fine under LabWindows 7 but with 2010 we are having problems.

[Ian.W]

Looks like we need some better (NI?) help here.

The only last thing I can think of is that the version of the RTE you are using might be a factor. They are remarkably backward compatible, but it might be worth checking.

Hopefully someone more qualified can join in with some ideas 😉