Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

Anonymous types (3) ASP.NET (5) C# tricks and tips (2) Computers (4) Design patterns (3) DomainDataSource (3) Dynamic data (4) Entity model framework (7) LightSwitch (11) Linq (6) Microsoft (1) MVP (2) MVVM (2) RIA services (5) Silverlight (1) SQL Server (1) Unit testing (4) Visual Studio (5) WCF (3) WPF (2)



Blogroll - Fav Blogs


The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Actually, as I'm self-employed, I guess that means that any views I expressed here aren't my own. That's confusing!

About me


Theme modified from one by Tom Watts
C#/HTML code styling by Manoli

My rambling thoughts on exploring the .NET framework and related technologies
Home of the surprisingly popular Pixata Custom Controls For Lightswitch (well, it was a surprise to me!)

I was recently involved in a discussion on the Lightswitch forum, in which someone asked about updating the data in the view model before the current control lost focus. He was using a modal window that had only one text box on it, and wanted to set the enabled status of the OK button, depending on what was in the text box. The problem he had was that the ABCCanExecute method only fired when the text box lost focus, which couldn’t happen as there weren’t any other (enabled) controls on the window. I suggested an answer, which led me to remember a similar issue I had contemplated some time ago...

As part of my Pixata Custom Controls For Lightswitch extension, I wrote a control that displays a clickable web link. You can see the control to the right of the text box holding the web address in the screen shot below. If you click on the link, it would open the web page in your default browser.

The web link control on a Lightswitch screen

An issue I had with this was that when I changed the text in the text box, the clickable link would only be updated when the text box lost focus. I wanted the link to change as I typed.

I had a play with this today, and realised that whilst the answer is pretty simple, it might be worth blogging about it.

The way to get around this is to capture the TextChanged event of the text box, and manually update the view model data. The steps to do this are as follows:

1) In the InitializeWorkspace method of the screen, grab the text box (or strictly speaking, grab a proxy for it), and subscribe to the ControlAvailable event. This means that when Lightswitch paints the control on the screen (which might not always be as the screen is first displayed), you have access to the text box.

2) Save the text box in a private variable, so you can get at it later if you need to. This step isn’t strictly necessary, but I often do it as it comes in useful.

3) Subscribe to the text box’s TextChanged event, and in the handler, grab the updated text.

Here is some code that shows it in action...

   1:    partial void FerretsDetail_InitializeDataWorkspace(List<IDataService> saveChangesTo) {
   2:      var WebTextBox = this.FindControl("WebTextBox");
   3:      WebTextBox.ControlAvailable += new EventHandler<ControlAvailableEventArgs>(WebTextBox_ControlAvailable);
   4:    }
   6:    private TextBox webTextBox;
   7:    void WebTextBox_ControlAvailable(object sender, ControlAvailableEventArgs e) {
   8:      webTextBox = (TextBox)e.Control;
   9:      webTextBox.TextChanged += new TextChangedEventHandler(webTextBox_TextChanged);
  10:    }
  12:    void webTextBox_TextChanged(object sender, TextChangedEventArgs e) {
  13:      Ferrets.Web = webTextBox.Text;
  14:    }
  15:  }

On line 2, we get hold of the IContentItemProxy, which is basically something that stands in for the control until it is available. On line 3, we subscribe to the ControlAvailable event, which is on lines 7-10. Line 6 contains the declaration for the variable that will store the text box in case you need it later. On line 8, we pull the text box itself out of the event args that were passed in, and on line 9 we subscribe to the TextChanged event. Line 13 simply grabs the text form the text box, and pushes it into the Web property of the screen’s query (which in this case is called Ferrets).

The end result of this is that as you type in the web text box, the link text (and underlying address) is changed in real time.

This technique can be extended to do all sorts of clever things, removing some of the natural limitations of working in a Lightswitch screen.

Categories: LightSwitch
Comments are closed.