Creating Cascading Drop Down ListsA common technique on data entry screens is using one drop down list (called an auto-complete box in LightSwitch) as a filter into the next. This limits the amount of choices that need to be brought down and guides the user into easily locating values. This technique is also useful if you have cascading filtered lists where the first selection filters data in the second, which filters data in the next, and so forth. LightSwitch makes this easy to do using parameterized queries and parameter binding. In this post lets take a look a couple common scenarios.

Cascading Lists based on Multiple TablesLets take an example where we have a table of States and a child table of Cities. Cities are then selected on Customers when entering them into the system. So we have one-to-many relationships between State and Cities and City and Customers. Our data model looks like this:

When the user is entering new customers we dont want to display thousands of cities in the dropdown to choose from. Although the users can use the auto-complete box feature to locate a city, bringing down all these records affects performance. Its better to either use a Modal Window Picker search dialog (like I showed in this article) or present the list of States first and then filter the list of Cities down based on that selection. First we need to create a couple queries. The first will simply sort the list of States so that they show up in alphabetical order in the list. Right-click on the States table in the Solution Explorer and Add Query to open the Query Designer. Create a query called SortedStates that sorts on the states Name Ascending:

Next create a query called CitiesByState by right-clicking on the Cities table in the Solution Explorer and selecting Add Query again. This time we will create a parameterized query: Where the State.Id property is equal to a new parameter called Id. The Query Designer should now look like this:

Now create the Customer Detail Screen like normal. Right-click on the Screens node and select Add Screen, select the Edit Details Screen template then choose Customers for the screen data. The Screen Designer opens and all the fields in the Customer entity will be in the content tree. The City field is displayed as an auto-complete box.

Next well need to add a data item to our screen for tracking the selected State. We will use this value to determine the filter on the City list so that users only see cities in the selected state. Click Add Data Item and add a Local Property of type State called SelectedState.

Next, drag the SelectedState over onto the content tree above the City. LightSwitch will automatically create an auto-complete box control for you.

Since we want to display the states sorted, next add the SortedStates query to the screen. Click Add Data Item again, this time select Query and choose SortedStates.

Then select the SelectedState auto-complete box in the content tree and on the Properties window, set the Choices property to SortedStates.

Next, add the CitiesByState query to the screen and set that as the Choices property of the Cities auto-complete box. Again, click Add Data Item and choose the CitiesByState query.

Then select the Cities auto-complete box and set the Choices property to this query.

Lastly we need to hook up the parameter binding. Select the Id parameter of the CitiesByState query and in the properties window set the Parameter Binding to SelectedState.Id. Once you do this a grey arrow on the left side will indicate the binding.

Once you set the value of a query parameter, LightSwitch will automatically execute the query for you so you dont need to write any code for this. Hit F5 and see what you get. Notice that the Cities drop down list is empty until you select a State at which point it feeds the CitiesByState query and executes it. Also notice that if you make a city selection and then change the state, the selection is still displayed correctly, it doesnt disappear. Just keep in mind that anytime a user changes the state, the city query is re-executed against the server.

One additional thing that you might want to do is to initially display the state to which the city belongs. As it is, the Selected State comes up blank when the screen is opened. This is because it is bound to a screen property which is not backed by data. However we can easily set the initial value of the SelectedState in code. Back in the Screen Designer drop down the Write Code button at the top right and select the InitializeDataWorkspace method and write the following:Private Sub CustomerDetail_InitializeDataWorkspace(saveChangesTo As List(Of Microsoft.LightSwitch.IDataService)) ' Write your code here. If Me.Customer.City IsNot Nothing Then Me.SelectedState = Me.Customer.City.State End If End Sub

Now when you run the screen again, the Selected State will be displayed.

Cascading Lists Based on a Single TableAnother option is to create cascading lists based on a single table. For instance say we do not want to have a State table at all. Instead it may make more sense to store the State on the City. So our data model could be simplified by

having just a City table related to many Customers.

This time when we create a parameterized query called CitesByState, well set it up Where the State is equal to a new parameter called State.

On the screen, select Add Data Item to add the CitiesByState to the screen and set it as the Choices property of the City auto-complete box just like before.

This time, however, the State is the query parameter we need to bind. Add a string screen property to the screen to hold the selected state. Click Add Data Item again, add a required Local Property of type String and name it SelectedState.

Drag the SelectedState onto the content tree above the City. This time LightSwitch will create a textbox for us since this is just a local string property.

Finally, we need to set up the query parameter binding. Select the State query parameter and in the properties window set the Parameter Binding to SelectedState.

In order to set the SelectedState when the screen opens, the same code as before will work. Now when we run this, you will see a textbox that will filter the list of cities.

However, this may not be exactly what we want. If the user has a free-form text field then they could mistype a state code and the query would return no results. It would be better to present the states in a auto-complete box like before. Close the application and open the Screen Designer again. Select the SelectedState screen property. Notice in the properties window you can display this as a static list of values by creating a Choice List.

Enter the states that the user should select from and then run the application again. Now we get an auto-complete box like before. However, this approach leaves us having to define the choice list of states on every screen we want this functionality. The first approach using a State table solves this issue but there is also one other approach we could take to avoid having to create a separate table.

Using a Choice List on the EntityWe could improve this situation by defining the choice list of states on the Customer entity. Then we would only have to define the lists of states in one place. Create a State property on the Customer using the Data Designer and on the properties window select Choice List and specify the list of states there.

Now add a new detail screen for Customer and you will see the State and City properties are set up as autocomplete boxes. Next add the CitiesByState query to the screen by clicking Add Data Item like before. We can use the same CitiesByState query as the previous example. Select the City auto-complete box and in the properties window set the Choices property to CitiesByState like before. The difference is the query parameter binding. Select the State query parameter on the left and in the properties window set the Parameter Binding to Customer.State.

With this technique, you also do not need to write any code to set the initial selected State because we are now storing that value on the Customer record. Run the application again and the screen should behave the same. The only difference now is that we are storing the State on the Customer instead of a separate table.

This technique is the simplest to set up, so if you have a lot of Customer screens, then this may be the best choice for you if you have a static list of values like States. However if you have dynamic list of values then its better to store these in a separate table like the first technique showed. http://blogs.msdn.com/b/bethmassi/