Clear related value lists

[TonyInSeattle]

I have two related drop-down menus. My selection in the first menu affects what I see in the second.

Produce Type (fruit, vegetable)

Produce Kind (apple, pear, carrot, celery)

For example, if I choose "fruit" in the first drop-down, my choices in the second drop-down are apple and pear, so I choose one of those, say, apple.

Problem is, I can go back up to the first drop-down list and change my selection to vegetable. Now I've got "vegetable" as a produce type, and "apple" as a produce kind.

How can I ensure that if the user changes a selection in the first drop-down, the contents of the second drop-down field are cleared so I'm forced to make another choice?

[Wim Decorte]

overlay a button on the first value list that:

- sets the second field to ""

- enters the first field

[TonyInSeattle]

That works! But any time you click in the field, you'll automatically erase the related field(s), even if you don't end up changing the value in the first field.

Is there a way to erase the other two fields only if I end up changing the value in the first field?

[comment]

Yes, there is.

condVL2_clear2.fp7.zip

[TonyInSeattle]

Wow! Thank you! I really appreciate you taking the time to show me the solution. It works perfectly...

[The Gardener]

Comment,

Brilliant! So elegant, and, compact. Thanks for posting the link to your file here yesterday

[Søren Dyhr]

Michael, could you give some benefits from using your approach against:

Evaluate ( Quote ( "" ); PrimarySelection)

...stufffed in the autoenter(UD): I know it can be written even simpler by the use of esc's but tougher to read.

--sd

[comment]

I believe Evaluate() should be used when you need an expression to be evaluated. Using it for its triggering mechanism alone is inefficient (see more on that here. I have no proof of that, but it seems reasonable to me.

Not to mention that the structure of "this is the trigger, and this is the result" makes the logic of the calculation practically jump out at you.

[Søren Dyhr]

Perhaps it's jumping out at you, but exactly the example you write about in the referenced thread, have not been moderated or altered from version to version of the "Using Filemaker X..."

So your reservations havn't made much impact on Scott Love and gang ...YET!

should be used when you need an expression to be evaluated

But as such isn't there much disitinction in making a value versus a null value in my humble opinion ...Remember I do as one of my trademarks/idiosyncracies use Case(0;0) ...instead of either esc'ing or Quote(

--sd

[comment]

Well, I can only state my own opinion...

I missed your second point. I am still looking for a problem where Case(0;0) would be a solution, so I don't really need to consider alternatives for it.

[bobearl]

Incredibly useful series of posts on conditional value lists; many thanks - I believe I'm starting to get an inkling.

I do have one question, which I'm asking so that I might better understand the various alternatives. Instead of having one TO of table and two of values as comment did, I got similar results from creating one table each of the values themselves and of a value catalog. Is there a way to assess which approach will be most efficient/clear?

VeggieTales.fp7.zip