Note: This article has been updated for Beta 2 on 3/17/2011
LightSwitch, by default, intelligently generates UI based on the shape of an entity. For example, adding an Employee entity to a screen might generate a TextBox for Employee.Name, a DatePicker for Employee.Birthdate, an Auto-Complete Box for Employee.Gender, etc.
Some screens, however, require UI that simply guides the user to complete certain tasks. This UI may not directly represent a stored value in the database. For example, you may have a CheckBox that controls the visibility of a section of the screen. The CheckBox itself does not directly reflect a stored value in the database. It is a local screen property.
In this post, we will create a simple flight search screen. Similar to any travel website you may have used in the past, it contains a couple of dropdown lists, date pickers for the user to input search criteria. It will show and hide a piece of the UI based on the value of another. We will achieve this by creating several local screen properties.
Here is the sketch of the UI we want to build. Let’s start!
Start with data
We will start by adding an Airport table via the Entity Designer:
- Name (String, required)
- City (String, required)
- State (String, required)
- Code (String, required)
We can also add a summary field to the Airport table so it has a meaningful string representation by default. For more details of how to customize an entity’s summary field, please see Getting the Most out of LightSwitch Summary Properties by Beth Massi.
In this example, we will use:
Private Sub Summary_Compute(ByRef result As String)
result = City & ", " & State & " (" & Code & ") – " & Name
Assuming we already have some Airport data in the database, you will see the airports show up in this format by default. Here, I‘ve created a list-details screen to enter some airport data.
Create a screen
Let’s create a screen called SearchFlights via the “Add New Screen” dialog. We will use “New Data Screen” template with no screen data included.
Click OK. Screen designer will appear. You should have a screen like this:
Based on our sketch, we need the following UI elements:
- An AutoCompleteBox to specify the origin
- An AutoCompleteBox to specify the destination
- A DatePicker to specify the departure date
- A DatePicker to specify the return date
- A CheckBox to indicate whether to include return trip in the search result
Each UI element represents a piece of screen data. Therefore, we need to add some screen properties to the screen first. Click “Add Data Item” button in the command bar to open “Add Screen Item” dialog.
Add a local property of type Airport called FromAirport. In the property sheet. Similarly, add another property called ToAirport.
Add a local property of type Date called LeaveDate. Similarly, add another property called ReturnDate.
Finally, add a local property of type Boolean called RoundTrip. This property indicates whether we should include the return trip in the search results.
We have now added 5 local properties: FromAirport, ToAirport, LeaveDate, ReturnDate, and RoundTrip. You should have these screen properties in the screen designer.
We can now create some screen UI for these screen properties. Based on our sketch, the layout requires 2 groups. One group uses a “Rows Layout” containing the airport dropdowns. The other uses a “Columns Layout” containing the date pickers and checkbox.
Therefore, we will add two groups to the screen content tree, one using “Rows Layout,” the other using “Columns Layout.”
Using the “+ Add” button, add From Airport to the first group.
Similarly, add To Airport to the same group.
Next, add Leave Date, Return Date, and Round Trip to the 2nd group.
Select the screen root node. Set the “Label Position” property to “Top” in Properties. This will position the display names on top of the controls. Also set the “Vertical Alignment” property to Top in Properties.
Let’s run the application (F5) and see what we’ve got.
Write some screen code
We’re pretty close to what we want! However, there are a couple of things we can improve. First, the Leave Date and Return Date are not being initialized to a reasonable value. Second, when Round Trip is unchecked, we want to hide the Return Date UI.
We can achieve these by writing some code for the Search Flights screen. Let’s go back to the screen designer. Right click on SearchFlights in the Solution Explorer and choose “View Screen Code.”
First, we want LeaveDate to be to today’s date and RoundTrip to be true by default. We can do this in the <Screen>_InitializeDataWorkspace event.
Private Sub SearchFlights_InitializeDataWorkspace(saveChangesTo As System.Collections.Generic.List(Of Microsoft.LightSwitch.IDataService))
LeaveDate = Date.Today
RoundTrip = True
Next, we want ReturnDate to be 7 days after the LeaveDate whenever it is changed. We can do this in the <Property>_Changed event.
Private Sub LeaveDate_Changed()
ReturnDate = LeaveDate.Date.AddDays(7)
Finally, we want to show and hide the ReturnDate’s DatePicker based on the RoundTrip property.
Private Sub RoundTrip_Changed()
FindControl("ReturnDate").IsVisible = RoundTrip
FindControl allows you to reference a control by its programmatic name. In this case the programmatic name of the ReturnDate DatePicker is “ReturnDate.” You can find the programmatic name from the “Name” property in Properties.
That’s it! Now run the application. The dates are initialized properly, and the CheckBox now controls the visibility of the Return Date.
What’s next? Now that we have the search criteria on the screen, we can simply bind these properties to a parameterized query that returns a list of qualifying flights. For more information on parameterized queries, please see How to use lookup tables with parameterized queries by Karol Zadora-Przylecki.
Hope that helps!