GetCtrlVal problem with toggle button in LabWindows/CVI

[NeilQ]

I am using Labwindows/CVI 5.0.1.

My aim is to use a toggle button to control a digital output using the
following Callback.

//--------------------------------------------------------------------
int CVICALLBACK operate_mci (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
char control_value;

switch (event)
{
case EVENT_COMMIT:
//toggle mci output
GetCtrlAttribute (IPBpanelHandle, control, ATTR_CTRL_VAL,
&control_value);
DIG_Out_Line (DIO, IPB_SWITCH_PORT, IPB_MCI, !control_value);

break;

}
return 0;
}


My problem is that this code fails at run time with the message,
"array argument to small" and it refers to the "&control_value".

My understanding from the extremely limited references to toggle buttons
in the manuals is that a toggle button control has a value of either 1
or 0. I have determined from table 3-12 of the User Interface reference
that the attribute "ATTR_CTRL_VAL" is the "same type as control type"
however I have not found anything that defines what type a Toggle button
control is.

I have tried every control type in the list of control types, each
generates an error. Most in the form "found pointer to short int,
expected pointer to char". The exceptions are when I define
control_value as char or unsigned char and in both cases I get the
"array argument to small" message.

Have you any suggestions as to where I am going wrong with this?

[RobertoBozzolo]

Toggle buttons are usually expected to be of type 'int', so I will change your code as follows:

int control_value;

GetCtrlVal (IPBpanelHandle, control, &control_value);
DIG_Out_Line (DIO, IPB_SWITCH_PORT, IPB_MCI, (short)!control_value);

Roberto

[NeilQ]

Roberto,
I agree, this is exactly how I first attempted it. Just to confirm I have retried the code and it generated the error "found pointer to int, expected pointer to char".

I am hoping I have missed something else, it would be a nuisance if my problem is a result of another system bug.

Thanks for your reply.
Neil

[RobertoBozzolo]

Neil,
some times has happened to me that I worked on different controls that I expected due to wrong handles passed to functions.
That is: I noticed that in your operate_mci callback function you use 'control' as the control handle (that is: you get the value of the control that triggered the callback) but you use IPBpanelHandle as the panel handle instead of using 'panel' (the panel handle passed by CVI to the function): are you sure that 'panel' and IPBpanelHandle point to the same panel or, said another way, that the control that triggers the callback lies on the panel pointed to by IBPpanelHandle? Maybe you are actually pointing to a string control or indicator on another panel, that can cause the type of error you get.
Seems a silly quest
ion but sometimes we deep into hard questions not seeing evident problems...
If this is not the case it's difficult to understand the behaviour you say without looking at your code.
Hope it helps.
Roberto

[Shiner]

I suspect that your IPBpanelHandle is not a handle to your "panel" upon which the the control exists.
I believe that it just so happens that the value you are using is valid for another panel already loaded (maybe the main panel), and that the control variable is now pointing to another valid control (such as a text box or something).

I think the function uses void and void* so it cannot be verified at compile time that the function will work. Its only during runtime when incorrect panel handle and / or control has accessed the wrong type of variable.

One other suggestion is not to use the control variable from the Callback but to use the #defined value for the control from the UIR Header file, or if progrmatically created, use another reference other than the one
passed into the callback function.

Hope this helps,

Chris

[NeilQ]

Thanks Chris,
This will be it for sure, some times it does not matter how long you look you will still not see the obvious!
Cheers
Neil

[Shiner]

I've done the same thing a number of times, still bites me every now and then...