HI @cbeemsterboer, thanks for your question. I don’t think the logic of FME will support the way you’d like the scripted parameter to pass its value to the CLIP parameter before the translation is initialized. Even though scripted parameters are executed before start-up Python scripts and the translation itself, they wouldn’t be executed just by choosing a dependent value in the runtime Parameter Prompt. In other words, you would need to hit “Run” on the Parameter Prompt to execute your scripted parameter, which in turn closes the Parameter Prompt.

As a result, users would never see the dependent parameter, and so would never get the chance to check its checkbox. This is why the value of that BGT_CLIP parameter is always NO, even though the scripted parameter does pick up the BGT dataset and return the value of “1”; users never get to see that BGT_CLIP checkbox as the Parameter Prompt closes before the scripted parameter runs.

I think a way around this might be to include a Yes/No published user parameter instead of a scripted parameter. Place the new Yes/No published user parameter just below the DATASET parameter in the User Parameter Manager. Then, set the prompt of the Yes/No published parameter to something like:

Did you choose to download the BGT dataset?

Finally, set the conditional visibility of the BGT_CLIP parameter to the value of the new Yes/No parameter. This adjustment should result in the BGT_CLIP parameter’s visibility being controlled by the value of the Yes/No parameter, and users should be able to see this BGT_CLIP parameter appear in the Parameter Prompt when the choose to download the BGT dataset.

It’s an extra click from the user, but will achieve the goal of showing or hiding the CLIP parameter based on the datasets selected for download.

You do bring up a great point though; I’m going to file an enhancement on the conditional visibility functionality of published parameters, requesting an “Includes” option. This enhancement should allow for the type of functionality that you’re looking for, and would remove the need for an additional (somewhat extraneous) Yes/No user parameter.

Please let me know if you have questions on the above, I’m happy to continue the conversation as needed!

Would this setup work for you?

Or maybe even this:

Thank you @geomancer , that's what I have implemented now, because I couldn't think of another solution for it. It is okay and works, but I thought it would be a little ‘cleaner’ of it could be just one question for all datasets, since we want to implement more datasets in the future and then the list of user parameters grows with every dataset.

@natalieatsafe thanks for the explanation. The enhancement you are suggesting to implent the “includes” option would be great for these cases! For now I think I will make a yes/no question per dataset-type, as also suggested in the example given by @geomancer 

I think:

If PARAMETER IN (“DKK",”BGT”) would be a logical addition to the current IF PARAMETER = DKK

@cbeemsterboer @geomancer @jkr_wrk Thank you all very much for your feedback on this one. I’ve filed FMEENGINE-83765 to request the enhancement on the operators available for those conditional statements related to conditional visibility of user parameters. I’ll keep an eye on that ticket, and post an update to this thread once the enhancement has been committed to the FME Platform.