I use a checkbox set to set the value of a field, 'x'. The value list for the checkbox is based upon another field's values.

Let's say the other field's values are a,b,c, and d. The user has checked 'c'. Later the value list is different because the other field's values are now a,b,c, and e (d is no longer a field value and therefore no longer in the value list).

The checkbox set is now a,b,c, and e. The user checks 'e'. The value of the field is now 'd,e'. The old value, 'd', that no longer exists is still part of the value of field 'x'.

How do I get rid of the 'd' in the value of the field 'x'? If the field is displayed using the check box set, there is no misinformation. But if the field is displayed as an edit box, it is wrong. The field 'x' is used in various calculations and may give wrong results (if no box is checked, i.e. the field should be empty, I take a different action than if one or more fields are checked).

Is this a bug? Looks like one to me.

It's not a bug. Value lists are merely a device for entering data into a field and displaying it. A value list does not control the CONTENTS of the field, and modifying a value list - by any means - will not affect the field contents. It would be a disaster if it did.

In your example, if you want to remove the value "d" from field x when "d" is removed from the value list, you have to do it yourself, for example by attaching an auto-entered calculation to field x (assuming the "other field" is in the same table).

If you only want one value in the field at a time, you could use radio buttons instead of checkboxes.

Multiple values being selected is an option, so the check box set is the correct format; not the radio button. This example was simplified to illustrate the problem.

I'm also not looking for a change in the value list to cause a change in the content of fields. Only that the next time the user wants to modify the contents of the field 'x' using the current value list, that the result of their selection contain only the values from the current check box set and not residuals from an earlier version of the value list.

I think that's a reasonable expectation.

I will probably have to do a calculation, but it seems I will have to treat the 'x' field as a list and check to see that each entry in the list is in the current value list. Not a very efficient procedure. Am I missing something?

It seems I didn't understand your question - and I am not sure I understand it now. If a value has been entered, and then the value list is modified so that the entered value is no longer a member of the list, the previously entered value will remain - and the user will not be aware of this. This is how it works by default.

It's up to you how - and more importantly WHEN - you want to handle this situation: by a calculation, field validation, script, etc. You could do literally what you said:

the next time the user wants to modify the contents of the field 'x' using the current value list, that the result of their selection contain only the values from the current check box set and not residuals from an earlier version of the value list.

This could be done by having the checkbox field auto-enter a calculation using the FilterValues() function. But if the user modifies the value list, and does NOT modify the checkbox field, the problem will already be there. It seems to me that the problem is created when the value list is modified, and should be dealt with then, instead of waiting until user decides to modify the checkbox field.

See also:

http://www.fmforums.com/forum/showtopic.php?tid/191362

It looks like the 'filter values' will do what I need. I didn't know it existed! I'll give it a try.

Thanks.

I'm also not looking for a change in the value list to cause a change in the content of fields. Only that the next time the user wants to modify the contents of the field 'x' using the current value list, that the result of their selection contain only the values from the current check box set and not residuals from an earlier version of the value list.

I think that's a reasonable expectation.

I will probably have to do a calculation, but it seems I will have to treat the 'x' field as a list and check to see that each entry in the list is in the current value list. Not a very efficient procedure. Am I missing something?

No I think you understand the situation quite well. I think your expectations are based on your users' needs rather than your understanding of FileMaker, but it's a learning process.

You'll need to set up the field as an auto-enter calculation. You'll probably need a custom function to compare the values in the field to the value list and strip out the unneeded values.