GetCtrlVal Value Returned does not match UIR

[blichtk]

I seem to have run into an issue with CVI 9.0.1.  The value returned by GetCtrlVal and GetCtrlAttribute do not track the values stored in the uir file .   For example, if for a binary switch I change the the "ON value" and "OFF value" for the switch from 0(off) & 1(on) to 1(off) & 2(on) the values retrieved dur program execution using GetCtrlVal() or GetCtrlAttribute (using ATTR_ON_VALUE) do not match the saved changes in the uir.   Occasionally the problem can be corrected by rebuilding release and debug executables but the solution is not reliable.  

I have seen this behavior for both binary switches and radio buttons.   I first noticed the issue (i believe) in 9.0. 

Has anyone else seen this or can they offer a work around?

[ebalci]

I think that is because the "Embed project UIRs" box is checked in the Target Settings dialog.

So the changes do not apply to the loaded panel during runtime, unless you rebuild the executable.

By the way, in my opinion, CVI should display a warning when the coder enables this option for the first time, for any project.

I sometimes forget that I enabled it, too. 

[blichtk]

Thanks for the tip but I do not think that is the issue.   First, when I discovered the problem I did verify that I completely rebuilt the project in debub mode, in release mode with cvi compiler and in release mode with visual stuido compiler.  However,  I do use the embed uir option so re-ran the test with the option checked and unchecked with the same results.

Any other ideas?

[blichtk]

Additional Information.

I saved the UIRs as TUIs (text files) and switched to having my LoadPanel load the TUI vs the UIR.   I verified that the ATTR_ON_VALUE and ATTR_OFF_VALUEs in the TUI match my edited panel.   However, GetCtrlAttribute and GetCtrlValue still return the incorrect value....

Anyone else see this BUG?

[LuisG]

I tried reproducing this problem and I wasn't able to. Can you try the attached program and see if it also works for you? If it does, then the next thing I'd suggest would be for you to send us your program to see if we can reproduce the problem here at NI.

Thanks,

Luis

Message Edited by LuisG on 06-29-2009 10:50 AM

[blichtk]

I have found the issue. I believe RecallPanelState() is not operating correctly --- or at least not a as I expected.

I call LoadPanel() and then RecallPanelState() on program startup as a convinience feature to the end user.  The recall

panel state is not only loading the last value chosen by a user of switches, radio buttons etc. as I would expect but is also loading all possible values of those switch and radio buttons.  So in my original example, even though my call LoadPanel() loads the updated values of switches (ie 1-off and 2-on) from the UIR or TUI, RecallPanelState() loads previous values of switches (ie 0-off and 1-on) overwriting the value loaded from the uir or tui.  

[LuisG]

Strictly speaking, SavePanelState and RecallPanelState only persist values, and not attributes. However, even though ATTR_ON_VALUE and ATTR_OFF_VALUE are attributes, they too have to be persisted as part of the panel state since they are tied to the values of the control.

Consider the following scenario:

• the on value is 10
• the off value is -10
• the switch is turned on, which means that the value of the switch (as returned by GetCtrlVal) is 10.

Now imagine that  you save the panel using SavePanelState, and then load the state onto a panel in which the control's on value is 1 and the off value is 0. You can see how there would be a problem if RecallPanelState replaced the value of this control with 10, but left the on value and off value as 1 and 0 -- the control would be in a bad state. Therefore, RecallPanelState has to blap all three values.

Luis