Drop-down selection based on another drop-down selection

Brad Chapman asked on August 21, 2017 03:21

It seems this is a common scenario with a common problem; what is the resolution with a drop-down selection based on another drop-down selection using bizforms?

I have a very simple requirement: two drop-down controls, one populated by an SQL query and another drop-down control populated by an SQL query using the first controls value in the where clause.

I know in normal ASPX coding this always presents difficulties if the postback is triggered by the change to the first drop-down controls value; i.e.; the second drop-down is rendered before the selection change is processed.

Does Kentico provide a solution to this scenario that does not involve building a custom form?

PS: I'm using v 8.1.7

Recent Answers


Trevor Fayas answered on August 21, 2017 15:09

Should not need to do anything custom, in the Form's "Fields" tab, when you select a property (say DropDown1), on the bottom there is a "Depends on" and "Has others depending on it"

Check "Has others depending on it" for DropDown1, then set DropDown2 to have "Depends On" Checked, and now when DropDown1 changes, the form will postback and dropdown2 will have the context it needs to adjust. Usually you would then use Macros and reference {% Fields["DropDown1"].Value %} i believe to use the current value.

0 votesVote for this answer Mark as a Correct answer

Peter Mogilnitski answered on August 21, 2017 15:15 (last edited on August 21, 2017 15:19)

I would assume the 2nd drop down doesn't have to be shown till a value in the first one is selected? Then it is pretty standard situation, for example: 2 drop downs

  1. country
  2. state (only visible if Canada (CountryID=309) is selected)

For country field you put data source - sql query (Select CountryID, CountryName from CMS_Country) and check 'Has depending fields'.

For state field: you set visibility condition and define query: Image Text

the state drop down will appear only if Canada (CountryID= 309) is selected

0 votesVote for this answer Mark as a Correct answer

Brad Chapman answered on August 25, 2017 04:21

Thanks guys. It appears that it may not be as simple as this in the version I am using. The dependent field connection is fine and well understood - I've been using this for ages now with no problems.

The issue appears to be the ability for the dependent field correctly use the preceding fields selected value in a subsequent SQL query.

It simply does not appear to work. The problem appears to be multiple;

A: The value must be numeric as the SQL field cannot correctly process the macro as shown in the above sample. e.g '{% Fields["DropDown1"].Value %}' will produce a string identical to that entered, whilst {% Fields["DropDown1"].Value %} will produce an error if the value is not numeric. This appears to be an SQL Injection prevention strategy.

B: The value only appears to be returned on the second post back; e.g.: the first post back will process the initial field value (an empty string) and the second post back the previously posted back value; this indicates the value change is being processed on selection change, not post back. The value MUST be processed on post back according to rendering precedence in .Net. (Preload, load, control, etc).

C: The second post back is the only one processed. All subsequent post backs appear to be ignored. This looks like a bug in 8.1.7.

Can I get some love from a Kentico rep on this one. This is basic functionality on any custom build yet it appears to be a brick wall in Kentico.

Cheers, and thanks for your time. Brad

0 votesVote for this answer Mark as a Correct answer

Trevor Fayas answered on August 25, 2017 15:40 (last edited on August 25, 2017 15:42)

Use {% Convert.ToInt(Fields["DropDown1"], -1) %} This will ensure if DropDown1 is not a number or null, the query will at least 'work' becuase it will give a -1 for the default value. I wonder if your issue is also a bug, Kentico 8 was a little buggy as it was a major jump from Kentico 7 and a lot of things were in transition.

As for the bug, looks like it's fixed in 8.2.4, so you will indeed need to hotfix. Going from 8.1 to 8.2 is very easy with the hotfix tool, but check documentation just in case. The only major difference in 8.1 and 8.2 is that jQuery is no longer by default added to websites, so you have to add it yourself (which was a huge improvement since there would be conflicts with Kentico's jQuery and your own).

1 votesVote for this answer Mark as a Correct answer

Brad Chapman answered on August 28, 2017 05:42

Thanks Trevor - thanks for the integer test trick. I'll look into the upgrade a little more closely. We've held off simply because of the drop in out-of-the-box plug-ins (galleries, etc) supported going from 8.1 to 8.2. Not a major thing technically, just an issue for the business time wise. Yes I agree; having to maintain a separate jQuery library is a pain.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.