History of setCtlVal

== Syntax ==

:int setCtlVal(int n, int v)

== Arguments ==

:n

::The index of the user control whose value you want to change

:v

::The value you want to assign to the user control

== Return ==

:Returns the previous value of control n, or -1 if n is not a valid control index.

== Description ==

:This function changes the current value of the user control with the index n. Note that the value set has to be one within the user control's range. Also note that not all user controls support value settings (for example, you can only save values in a FRAME user control when it is disabled).

== Example ==

<code>

setCtlVal(4, 30);

int iPrev = setCtlVal(5, 0);

</code>

== Also see ==

:ctl, getCtlVal

== Comments ==

:Everyone can add his comments about his experiences with this function here. Tips for using it are welcome, too.

=== setCtlVal() sets COMBOBOX control to 0 after 'OK' ===

*A user has reported this problem. What happens is that when you call setCtlVal() for a COMBOBOX or a LISTBOX, FM not only attempts to set the control to the desired value, but it also immediately reads back the value of the control and stores the read-back value as the new value for the control -- just in case, for example, you specify a value greater than the maximum value of the control, in which case the value is set to the maximum value instead.

*Now, if you call setCtlVal() after 'Ok' has been pressed, the actual control no longer exists (because the filter dialog has already been destroyed). In this case, the read-back value is 0, and that is what is cached as the new current value of the control, and what will be returned by a call to ctl or getCtlVal.

*Note that this control read-back occurs only for certain controls (e.g., COMBOBOX and LISTBOX), and not for others (such as sliders), so your results of calling setCtlVal() in this situation will vary, but in general it is a good idea to avoid calling setCtlVal() when the proxy preview dialog is not being displayed.

*Since this behavior, although "correct", is obviously not what the Filter Designer might be expecting, we will change the behavior of setCtlVal() in a future release of FM to always cache the requested value of a control in this situation.

*In the meantime, a suggested workaround is to use the doingProxy flag to bypass the "bug" in such a situation, as follows:

<code>

//avoid calling setCtlVal when no dialog is displayed

if (doingProxy) setCtlVal(n, v);

</code>