Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

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

Archives


Categories


Disclaimer

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!


>

Acknowledgments

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


>

My rambling thoughts on exploring the .NET framework and related technologies

# Sunday, February 7, 2016

Up until now, I have been using Manoli’s code formatter to add code to this site. I’ve had a couple of issues with this, mainly that the line numbers it includes are part of the text, so if you copy the code and paste it into Visual Studio, LinqPad, etc, you get the line numbers as well.

I recently discovered that Google have a code formatter, which seems to do the job nicely, doesn’t require you to paste the code into a formatter before adding it to the site, and uses an order list HTML tag to create the line numbers. It also has a few extra themes, meaning I can colour the code to look more like the dark theme I use in VS.

Here is some C# formatted with the new method…

public long MaxProduct (string s, int n) {
  return Enumerable.Range (0, s.Length - n + 1)
      .Select (i => s.Substring (i, n))
      .Max (s1 => s1.ToCharArray().Aggregate (1, (long a, char c) => a * (c - '0')));
}

Hmm, judging by the preview in Live Writer, it looks pretty awful! Shame, it looked fine in a plain HTML file. Have to post it to the blog and see how it looks there.

Edit: Looked OK. Shame I can't read the code when editing! Let's try some F# and see...

// Find the sum of all primes below two million
let primes max = 
    let array = new BitArray(max, true);
    let lastp = Math.Sqrt(float max) |> int
    for p in 2..lastp+1 do
        if array.Get(p) then
            for pm in p*2..p..max-1 do
                array.Set(pm, false);
    seq { for i in 2..max-1 do if array.Get(i) then yield i }

primes 2000000 |> Seq.map (fun n -> bigint n) |> Seq.sum

OK, I’m convinced!

Sunday, February 7, 2016 5:00:00 PM (GMT Standard Time, UTC+00:00)

The problem

As I briefly mentioned in my rant about the F# fanboy lies, I have been using Project Euler to help me learn F#. I have got as far as problem 8, which was to find the largest product in a series of digits. To save you the bother of clicking the link, here is the description…

The four adjacent digits in the 1000-digit number that have the greatest product are 9 × 9 × 8 × 9 = 5832.

73167176531330624919225119674426574742355349194934
96983520312774506326239578318016984801869478851843
85861560789112949495459501737958331952853208805511
12540698747158523863050715693290963295227443043557
66896648950445244523161731856403098711121722383113
62229893423380308135336276614282806444486645238749
30358907296290491560440772390713810515859307960866
70172427121883998797908792274921901699720888093776
65727333001053367881220235421809751254540594752243
52584907711670556013604839586446706324415722155397
53697817977846174064955149290862569321978468622482
83972241375657056057490261407972968652414535100474
82166370484403199890008895243450658541227588666881
16427171479924442928230863465674813919123162824586
17866458359124566529476545682848912883142607690042
24219022671055626321111109370544217506941658960408
07198403850962455444362981230987879927244284909188
84580156166097919133875499200524063689912560717606
05886116467109405077541002256983155200055935729725
71636269561882670428252483600823257530420752963450

Find the thirteen adjacent digits in the 1000-digit number that have the greatest product. What is the value of this product?

Apart from the fact that this was an interesting problem, I learnt a very important lesson from this one, and thought it worth sharing.

Solving the problem - or not!

My initial stab at this looked like this…

   1:  let chop n (s : string) =
   2:    [ for i in [0..(s.Length - n)] do yield s.[i..(i + n - 1)]]
   3:  let product (s : string) =
   4:    s |> Seq.fold (fun p c -> p * (int (string c))) 1
   5:  let lgstProduct n (s : string) =
   6:    s |> chop n |> Seq.map product |> Seq.max

The chop function chops the string into chunks of length n, the product function calculates the product of the digits (assuming that the string passed in only contains numbers of course), and the lgstProduct function sticks these together to find the maximum product.

I tried this with the 1000 digit number passed as a string, and using 4 for the chunk size, and it produced the right answer, 5832. Wanting to make the code shorter and neater, I included the two helper functions in the main one, and managed to come up with this...

   1:  let largestProductInt64 (n : int64) (s : string) =
   2:    [ for i in [0L..((int64 s.Length) - n)] do yield s.[(int i)..int(i + n - 1L)]]
   3:    |> Seq.map (fun s -> s, s |> Seq.fold (fun p c -> p * (int64 (int (string c)))) 1L)
   4:    |> Seq.maxBy snd

Note that I changed the code to give me a tuple, containing both the highest product, and the n-character chunk that produced it. Chuffed to bits, I threw the number 13 at it, and got the answer ("9781797784617", 2091059712) , which I duly plugged into the answer box on the Project Euler site, only to be told that it was wrong! What a chutzpah! Of course it’s right, my code works!

Or does it?

So what went wrong?

Having spent quite a bit of time testing my code, and convincing myself that it was right, I resorted to searching for other people’s answers to the same problem. Along the way, I came across someone who had had exactly the same problem as me, albeit in C++, and had come up with the same (wrong) answer.

It turns out that the issue was simple. When multiplying 13 digits together, you could potentially end up with 9^13, ie 2,541,865,828,329. Given that the maximum number that can be stored in the .NET int type is 2,147,483,647 the problem becomes apparent.

I changed my code to use int64, which is the F# equivalent of the .NET “long” type, and can hold numbers up to 9,223,372,036,854,775,807. Lo and behold, project Euler acquiesced, and accepted my answer.

In order to make my code even more general, I actually changed it to use bigint, which can hold any size of integer, but the point I want to take away from this remains the same…

What I learnt in school today

I think there is a very important lesson here. Like many of us, I piled in and started coding without really thinking about the problem. What I should have done is take a look at the problem domain, and think it through. It should have been obvious that the eventual product was going to be too large to fit into a 32-bit integer, which is probably why the Project Euler people chose such a large number in the first place. Had I done that, I would probably have got the right answer first time.

Now, I don’t know about you, but I almost never get these sorts of interesting problems in my day job. I usually get “Pull the data from the database, display it on a window, wait for the user to make changes and then save it,” which is significantly less interesting. However, I think the basic point remains valid. Without thinking through the scope of the problem, and the bounds of the domain, it’s very easy to pile and and get coding, whilst introducing all sorts of subtle bugs. My tests worked absolutely fine, simply because I was testing on small numbers. How many times do we developers test our code against a Noddy database, mainly to save development time? No need to put your hands up, we’re all guilty.

Had my largest product function been production code, I would have released a bug that would only have been spotted some time down the line. Depending on how easy/hard it would be to predict the right numbers, it’s possible that it might not have been spotted for a long time. People would just assume that the number produced was correct.

So, am I going to contemplate my problem domain before diving in and coding next time? Probably not, but at least if I don’t, I might have some idea where to look when the bug reports come in!

Improving the code

Having sorted all that out, I asked for a code review, and came across a really useful F# function that I hadn’t seen before. My chop function, included as the first line of my slimline largestProduct function split the input string into a sequence of chunks of length n. It turns out that F# has the Seq.windowed function that does exactly the same thing, but is more readable.

I also got a slightly better understanding of function composition, and saw how to reduce the number of brackets needed to convert the character to a bigint. I ended up with…

   1:  let largestProduct n (s : string) =
   2:    Seq.windowed n s
   3:    |> Seq.map (fun s -> s, s |> Seq.fold (fun p c -> p * (string >> bigint.Parse) c) 1I)
   4:    |> Seq.maxBy snd

I was quite pleased with this. A lot of functionality in four lines.

Solving the problem in C#

I was interested to see if I could solve the problem in C# as well, so I fired up LinqPad and jumped in. My initial version (including the extra bits need to run it in LinqPad, and the line to write out the result) looked like this…

   1:  void Main() {
   2:    string s = "7316...3450"; // NOTE: Snipped for brevity!!
   3:    int n = 13;
   4:   
   5:    var maxProduct = MaxProduct(s, n);
   6:    Console.WriteLine ("1) Max product is " + maxProduct.Item2 + " from " + maxProduct.Item1);
   7:  }
   8:   
   9:  public Tuple<string, long> MaxProduct(string s, int n) {
  10:    return Chop (s, n)
  11:      .Select (s1 => new Tuple<string, long> (s1, Product (s1)))
  12:      .OrderByDescending (t => t.Item2)
  13:      .First();
  14:  }
  15:   
  16:  public long Product (string s) {
  17:    long res = 1;
  18:    for (int i = 0; i < s.Length; i++) {
  19:      res *= Convert.ToInt32 (s [i].ToString());
  20:    }
  21:    return res;
  22:  }
  23:   
  24:  public IEnumerable<string> Chop (string s, int n) {
  25:    for (int i = 0; i < s.Length - n + 1; i++) {
  26:      yield return s.Substring (i, n);
  27:    }
  28:  }

Hmm, quite a lot of code there. Looks like F# really is shorter and cleaner!

There must be a way to improve this. A few moments’ thought made me realise that the Product() method is really doing what the Linq Aggregate() extension method does. Also, the Chop() method could easily be done with Linq if I fed in a range of numbers for the starting positions of the substring (like I did in my original F# code).

After a short bit of fiddling, I came up with this rather improved C# version…

   1:  public long MaxProduct (string s, int n) {
   2:    return Enumerable.Range (0, s.Length - n + 1)
   3:        .Select (i => s.Substring (i, n))
   4:        .Max (s1 => s1.ToCharArray().Aggregate (1, (long a, char c) => a * Convert.ToInt64 (c.ToString())));
   5:  }

That's much better! Once you ignore the extraneous bits, the body of the actual method is only three lines, a mere one line longer than the F# version. The F’'# is definitely cleaner, but as I’ve mentioned before, that’s not always an advantage.

After passing this problem around the team, one of the brighter sparks came up with an even shorter version that runs faster…

   1:  public long MaxProductEC (string s, int n) {
   2:    return Enumerable.Range (0, s.Length - n + 1)
   3:      .Max (i => s.Substring (i, n).Aggregate ((long)1, (a, c) => a * (c - '0')));
   4:  }

I defy anyone to tell me that C# is verbose! Don’t get me wrong, I’m really enjoying F#, but the lies are getting on my nerves!

All in all, an interesting exercise.

C# | F# | Project Euler
Monday, February 1, 2016 2:53:00 AM (GMT Standard Time, UTC+00:00)
# Monday, January 25, 2016

As my regular reader will know, I love anything shiny and new, and so was intrigued when I came across F#. When I was an undergraduate (some 25 years ago, ulp!), I played around with Prolog, and enjoyed the different approach to programming it offered.

However, as my time in front of the computer is at a premium, my F# learning started off with reading books and blog posts late away from the computer, usually last thing at night, and not actually doing any coding. Like most C# developers who come across F#, my initial reaction (other than “Hey, that’s shiny and new, I want to learn it!”) was “Why?” If you search around for terms like “why f#” and “c# vs f#” you’ll find that this is a very common question.

The problem is that the answers aren’t very good. Well, let’s be blunt, there are a lot of lies out there. Now before anyone starts flaming me in the comments (not that anyone ever reads this blog, much less leaves comments), I should point out that the criticisms that I can feel coming are not aimed at the F# community in general, nor are they aimed at F# itself. It’s the way people try to sell it that annoys me. I’ve been brooding over them for months, and have written this blog post in my head many times. I feel less strongly about it than I used to, so this will probably be a watered-down version of the original rant.

Wild exaggerations

As an example, I recently came across the following quote in an F# book… “No other .NET language is as easy to use and as flexible as F#!” (the exclamation mark was part of the quote, not my addition). Now this sort of comment really annoys me. Firstly, it’s completely unsubstantiated, and secondly, it’s totally subjective. Any language is easy to use and flexible if you learn it well enough. OK, maybe not any, Lisp is clearly only for weirdos (like my brother who loves it!), but let’s not go down that route. F# is not inherently easier than any other languages, and in some ways is quite a bit harder to learn, as it involves a significant shift in thinking to do it properly. Comments like that make me feel they are trying to cover something up, and have a negative effect – apart from the obvious feelings of antipathy towards the author.

Another idiocy was included a popular book by very well-respected member of the F# community, who attempted to sell F# by showing some pseudo-C# code, claiming that you can’t do this in C#, but you can in F#. Hey, isn’t F# great? My immediate reaction was to shout at the book “You can do that in C# if you bother to write it properly!” He had deliberately lied about what you can do in C# to try and show how F# is so much better. Given that the book was aimed at C# developers who wanted to learn F#, I thought this was a pretty dumb thing to do. A lot of the book went like this, and I shouted at it a lot!

The blogs weren’t any better. I read no end of them, telling me all the reasons why F# was better, and remained unconvinced. This was partly because some of the reasons given were simply not F# at all. For example, one of the most common reasons given for why we should all be using F# is F# Interactive. The point they all ignored is that FSI is not F#, it’s a tool that Microsoft happened to have implemented for F#, and hadn’t implemented for C#. As it happens, Visual Studio 2015 now includes a C# Interactive window, so this supposed benefit is no longer valid anyway. I doubt they’ll stop their bleating though.

Type inference

Another reason given for F# being the best thing since sliced bread is the type inference. Well, despite having struggled to understand the benefits, I’m still very doubtful about this one. Yes it makes the code shorter, but it makes it a whole lot harder to read. When I look at a piece of C#, I can see straight way the variable types and the method return types, so I can concentrate my mind on hat the code is doing. I can’t do that in F#. Having said that, when writing F#, the type inference is a joy, as you can concentrate on what the code is doing, and ignore the technicalities. It’s a two-edged sword, and not an undiluted benefit.

Well, it's so clean, sir!

The final claim I want to address is that F# code is so much cleaner than C#. Well, there is something in that, but clean isn’t necessarily better. I suspect most people will recognise the following snippet from what is arguably one of the funniest moments in comedy...

Customer (John Cleese): It's not much of a cheese shop, is it?
Owner (Michael Palin): Finest in the district sir!
C: (annoyed) Explain the logic underlying that conclusion, please.
O: Well, it's so clean, sir!
C: It's certainly uncontaminated by cheese.

Being clean can also be a disadvantage.

Apart from the specification of types (see above for why I’m not convinced that this is a bad thing), the only other part of C# that’s not clean is the fact that you have brackets knocking around, whereas F# is totally devoid of them. Again, this might make the code slightly shorter, but has its disadvantages. For example, if I have a few lines of C# code, and want to surround them with an “if” statement, I can just add the “if” statement on the line before the block, and a closing brace on the line after, then reformat the code, and all the indenting is done for me. I know the insertion will be right, as it can’t fail. If I want to do the same in F#, I have to concentrate a lot harder on adding the right amount of extra indentation to the lines I want inside the “if” block. It’s significantly more likely to go wrong.

If the few extra lines added by braces really bother you that much, go buy a bigger monitor! I can see around 70 lines of code on mine, so the few extra lines added by the braces rarely cause me any problems.

To make it even worse, when comparing evil C# code against the pure and sainted F# equivalent, they somehow always manage to stick as much extra code into the C# version as they can. F# snippets would be a method, and nothing else. The equivalent C# snippet would be a whole class, including usings. This is a false comparison.

I Red heart |> F#

By this point, you probably think I hate F#. Well, it’s not true. My point here is not anything against F#, it’s against the lies and exaggerations bandied around by the F# fan boys. I probably would have given up on F# in annoyance at these lies (as I suspect many, many others have done) were it not for the fact that I am fascinated my shiny new things. I decided to carry on anyway.

Thankfully, I discovered Project Euler. For those who haven’t discovered this wonderful site yet, it’s an ever-growing collection of mathematical and computer programming problems. Apart from my inherent love of such things, this was the perfect opportunity to learn F#.

Now you can use PE by simply solving the problems, entering your answer to check you got it right, and carrying on to the next one. I decided not to do that. I solved the problem, then went back and tried to find ways of improving my code. I posted my samples up for code review, and played around with the suggestions I got. I searched around for other people’s solutions (only after I had already solved it myself) to see if I could find better code. When I did, I copied it, played with it and made sure I understood it.

In time (not much actually), an amazing thing happened. I got really excited about F#! When you get into it, it’s a really nice language to use. I’m still not convinced that there are many major benefits over C# for my line of business (pull data from a database, display it on a window, wait for the user to make changes, save the data back to the database, etc), but for the sort of work that I would love to do, like machine learning, data analysis and so on, it seems wonderful. Sadly, I reckon my use of it will be largely recreational, unless I can find some justification for using it in my day job.

If I get around to it, I’ll post some of my Project Euler code here, so others can laugh at it, and feel better about their own code.

F#
Monday, January 25, 2016 8:00:00 PM (GMT Standard Time, UTC+00:00)
# Thursday, June 18, 2015

Having blogged recently about a stupid error message, I came across another one! Microsoft much employ people to craft these, they just couldn’t be there by accident. I reckon they are put there to amuse developers, and distract them from the fact that the software is misbehaving!

Anyway, I was using the SQL Server Import and Export Wizard, and it threw up the following error message:

Error 0xc004706b: Data Flow Task 3: "Destination 14 - EntityHistory" failed validation and returned validation status "VS_ISBROKEN"

I just love that last bit!

Thursday, June 18, 2015 9:16:00 PM (GMT Daylight Time, UTC+01:00)

And I’ve seen a few!

I was just trying to back up an SQL database, and got this truly wonderful error message...

Not much you can say to that is there?

Wednesday, March 18, 2015 3:14:00 AM (GMT Standard Time, UTC+00:00)
# Tuesday, January 13, 2015

My regular reader may remember that I wrote a while ago that my computer laughs at me. Well, it lies to me as well.

Bored of the usual methods of inflicting torture upon myself, I thought I would upgrade SQL Server 2008 R2 to SQL Server 2014 (stop laughing at the back!), because, erm, well it seemed like a good idea at the time.

First problem was that in order to upgrade, I had to apply service pack 2 to my existing SQL Server 2008 R2 installation. Why? No idea. I would have thought that if I were about to upgrade, it should have all of the later goodness in the upgrade, but who am I to question the ways of the wise?

So, I downloaded SP2 and set it going. Part way through, I got an unhandled .NET exception (nice one Microsoft, very professional), and when I clicked Quit, it continued with the installation! Still, as it seemed to work, I didn’t complain, but I was a bit annoyed that it lied to me. Computers aren’t supposed to do that.

Once I had SQL Server 2014 installed, I happened to notice that SQL Server 2008 R2 was still installed. Huh, I thought we upgraded to 2014? Shouldn't it have uninstalled 2008 R2? Well, I would have thought so too, but that just shows how much we know eh? If you have Visual Studio 2013 installed, you may well have SQL Server 2012 installed as well! Good job disk space is cheap nowadays.

Having asked about this in an SQL Server forum, I was told it was safe to uninstall anything related to SQL Server 2008 R2. Whilst doing so, I came across one component that gave me a message saying that SSMS 2014 depended on it, and if I uninstalled it, that would stop working. I clicked "No" to say I didn't want to uninstall this component, but it uninstalled it anyway! Didn't seem to matter, as SQL Server worked fine afterwards, so it just shows what liars they are!

I’m very disillusioned. No wonder the world is sinking into moral decay if you can’t even rely on your computer to tell you the truth!

Tuesday, January 13, 2015 8:49:00 PM (GMT Standard Time, UTC+00:00)

As my regular reader will know, when Lightswitch came out, I was quickly hooked. Like many people, I saw an answer to the hassle of creating n-tier desktop applications. It was a dream. Development time was slashed, and the few annoyances that there were paled into insignificance compared to the speed of development, and the quality of the end product.

I dived in head-first, and quickly came up against some of the limitations of a first version. That’s not a criticism, it’s more a testimony to the amazing power the first version had, that we could produce real LOB applications, and were frustrated by the missing bits.

Thankfully, Microsoft did a sterling job of adding extensibility points to Lightswitch, and despite the poor documentation (an ongoing feature of Lightswitch that caused a lot of wasted hours), the potential was there to fill in the gaps.

Inspired by early experimenters, like Yann Duran’s excellent Luminous Controls (which I still use in every Lightswitch project), I had a go at producing a custom control for Lightswitch, more for the fun of tinkering than anything else. Having worked out how to get going, I added a few more controls, until the first version of the Pixata Custom Controls For Lightswitch was born. Feeling that I had something that might be of use to others, I added it to the Visual Studio Gallery, and posting about it in the (now extinct) forum. I got so excited when it had 100 downloads!

Spurred on by the great feedback, I added more controls, and the control suite hit the top three for Lightswitch extensions. It varied between the first, second and third places, but has always been in the top three. To date, it’s had over 25,000 downloads, despite that the fact that I haven’t updated the controls for over a year.

Roll on a few years, and the mobile market exploded. Smartphones and tablets gained more power, and were able to browse the web almost as well as their desktop cousins. However, probably due to political more than technical reasons, the manufacturers chose not to support Flash or Silverlight on these devices, leaving Lightswitch out in the cold.

Microsoft, fairly understandably, decided to concentrate their efforts on producing a version of Lightswitch that would support mobile devices. That's where the HTML client came in.

This was fine, except for two huge problems...

1) The HTML client was (and still is from what I can see) woefully short of being ready for the job. It's a good start, but not good enough to create LOB applications. Specifically, despite the massive growth of the mobile market, Microsoft seem to have forgotten that the desktop world still exists, and still accounts of a very significant number of users, especially in the business world. Until the HTML client supports the desktop, it can't be considered ready for serious use.

I have other misgivings about the HTML client, but they are minor in comparison to this one. I know the mobile market is important, but in business-to-business work, which is a significant part of the software development world, you just can’t afford to ignore the desktop.

2) Whilst I don't think we can criticise Microsoft for moving away from Silverlight, which must have been hard for them, having put so much effort into producing a first-class product, what is totally unforgiveable (in my opinion at least, and I know I'm not alone) is the way they just dumped the Silverlight developers without any support. Their support for the more advanced side of Lightswitch was always poor, but when the HTML client came along, Silverlight client developers were just ignored completely. The extensibility forum died a sudden death, with unanswered questions making up the sum total of all posts.

Now, before I get criticised for this, I understand that they have limited resources, and want to concentrate their efforts on the latest and greatest, but many, many developers sunk a large amount of time and energy into Silverlight-related development, and to have all support cut off in an instant was a really dirty trick. I think we can all understand why they don’t want to invest more time in active development, but at least support what’s already there.

The problem became more acute as time went on, and Microsoft were pushing the HTML client with an evangelical fervour. It got to the stage where I knew that if I had a problem, there was little point in posting in a forum, as my post would be swallowed in a sea of HTML-related questions, and wouldn’t be answered by anyone at Microsoft anyway. The only way I could get an support was peer-to-peer support from some of the Lightswitch rock stars.

It came to a head for me recently when, having invested a significant amount of time in developing a complex application, it suddenly stopped working. The only clue I had was the rather generic error message “Cannot communicate with the database” when the application started. It worked fine on my development machine, and the database connections were all correct (I could even change the connection strings in Visual Studio, and run the application against the remote production database, so I know that wasn’t the problem), but the deployed version refused to work.

After struggling to get the attention of any Microsoft support person, I eventually had to give up and rewrite the entire application in WPF and ASP.NET WebAPI2. Surprisingly, it didn’t actually take that long, and left me wondering if Lightswitch is really as RAD as I had thought, once you get away from the basic functionality.

So, I’m left with a sour taste in my mouth, and some deployed Lightswitch applications that I’m terrified to touch, in case they mysteriously stop working as well. I can’t afford to rewrite them from scratch, and know that there is no way I’ll get any support if they stop working. I’m just hoping the customers don’t want any changes.

Sad end to a promising product. I have little interest in investigating the HTML client, as ASP.NET MVC makes it so easy to produce high-quality web sites that work in both desktop and mobile environments, and I can’t see any benefits in Lightswitch for this.

As for the controls? Well, I’ve made them open source, so if anyone wants to develop them further, they can.

Sunday, December 14, 2014 3:01:00 PM (GMT Standard Time, UTC+00:00)

Last February, I hit a problem where I was trying to implement printing from a Lightswitch screen, and was using what has now become known as the Command Table Pattern, which allows the Lightswitch client to send a command to the server. I was encountering an error with the witty message “A new instance of the EntityObject class cannot be initialized because the ambient IDataWorkspace is not available. Please use the constructor that specifies an EntitySet” which was as clear as mud to me!

I asked about this in the Lightswitch forum, and was greatly helped by the ace Lightswitch insider Justin Anderson, who patiently explained that the problem I was facing was to do with threads, dispatchers and workspaces. This area is one of those that seems to trip up a lot of people when they start digging into Lightswitch, and is very poorly documented. The few articles I have seen are fairly difficult to understand, which only compounds the problem. Thanks to Justin’s help, I got my code working, and got a better understanding of the subject.

Well, a few weeks ago, Steve added a comment to that forum post, as he was having a very similar problem when trying to create a new entity in the Click event handler of my Pixata Static Toolbar control. As I tried to explain what the problem was, I ended up explaining threads, dispatchers and workspaces, as he had hit exactly the same lack of understanding of these that led me to make the post in the first place.

He seemed to like my explanation, so I decided to post it here, as it may help someone else. Let me say in advance that this is not a comprehensive explanation, nor is it totally accurate, because it's a complex subject and I want to try and explain it in a way you'll understand. If any Lightswitch gurus are disgusted at my explanation, please feel free to leave a comment below, or email me Smile

Let’s deal with threads first...

In order to keep the UI responsive, Lightswitch uses two threads (think of two small men inside your PC, each one doing something different, but talking to each other to keep their work in synch). The main thread, let's call him Fred, handles getting data from the server and sending it back again. The other thread, whom we'll call Jim (because Jim is a good name) handles the UI stuff, like making sure the textboxes and comboboxes are drawn on the screen, and contain the right data.

When you do things like typing, choosing from a combobox, etc, you are talking to Jim. When you hit the Save button, this sends a message to Fred. You don't talk to Fred directly like you do to Jim, as Fred is in the background, round the back of your monitor where all the dust and dead flies collect, so when you click the Save button, what really happens is that Jim sends Fred a message saying "Here Fred, this one is for you." When Fred gets the message, he sends the data to the database for you.

The tricky bit is that there are two ways that the user tells Lightswitch what to do. One is through commands, which is how you work when you add a method to the screen (Click the "Add Data Item" button and choose "Method"). This sets up a command that just tells Jim to send a message to Fred, and have Fred do the work. However, if you capture control events, such as a button's Click event, then you are asking Jim to do the work himself, and not get Fred involved at all (he's cleaning up the dead flies while he's nothing better to do).

If that hasn't confused you, then you might have a very general (and rather flippant) idea of how threads work. When you are in a method created as a data item, you are talking to Fred, and Lightswitch creates a DataWorkspace for you. When you are in a control event handler, you are talking to Jim, and there isn't a DataWorkspace around. If you want one, you have to create one.

Aside: As my regular reader will know, I’m a huge fan of Lightswitch, but I do have one big gripe with it, and I think this is the cause of a lot of confusion to new Lightswitch programmers. In the name of good software design, Microsoft used the MVVM pattern when building Lightswitch. This is a familiar pattern to WPF and Silverlight programmers, and (like MVC and MVP before it), allows a clean separation of the business layer from the UI layer.

Now, in a normal (ie WPF or Silverlight application), the view model is in a completely separate file from the view. Thus, command methods are nowhere near control event handlers, which helps keep the separation clear in the mind of the programmer.

However, in Lightswitch, the view model code is in the same file as the screen’s code, meaning that you have methods sitting right next to each other that are actually going to be executing on different threads. I think this is a very bad idea, and seems to be the source of many problems I’ve seen in the forums.

Anyway, gripe over, back to Fred and Jim...

So, if we have two threads, how do they communicate? That’s where dispatchers come in. Dispatchers are a way of having Fred pass work to Jim and vice versa.

Certain tasks need to be done by Fred, as he works with the data. However, if you are inside a control event handler, then you are talking to Jim. So, what you need to do is ask Jim very politely if he will send a message to Fred asking him to do the work. That's where dispatchers come in.

You have two dispatchers, one that passes (ie dispatches) the work to Fred (also known as Main, as he handles the main work), and one that passes the work to Jim (known as Details). Remember, when you're writing code in a control event handler, you're talking to Jim, ie to the Details thread. For example, if you are in a control’s event handler, and you want to create a new entity (as Steve was), you need to pass the job to Fred, meaning that you need to use the Main dispatcher.

In Steve’s case, he didn't actually need a dispatcher, as he could have handled the problem a different way, but if he had, he would have needed the Main dispatcher, as he was already talking to Jim (remember the code was in a control event handler), and he wanted to pass the work to Fred. In such a case, you would do something like this...

    Dispatchers.Main().BeginInvoke(Sub() 
      ' code for Fred to do goes here 
    End Sub)

(Note that Steve was working in Visual Basic.NET, which is why I departed from the norm and didn’t use C# above)

I hope this has helped. If it's any consolation, I think dispatchers are about the most complex bit of Lightswitch there is. Hopefully, if you read the above a few times, it might make some sense. If you run into exceptions to do with threads, chances are you need a dispatcher. There are two ways to work out which one you need to use. The first is good old trial and error! Try one, and if it doesn't work, try the other. This isn't really a good approach, as you don't really get to understand what you're doing. The second approach is to keep reading and trying to understand it until it goes in.

The easiest way to think about it, which will probably work for you in most cases, is that if you are coding in an event control handler, then if you need to dispatch, you use Dispatchers.Main().BeginInvoke. If you are in a data item method, then you will need to dispatch using Me.Details.Dispatcher.BeginInvoke.

Although the DataWorkspace side of this issue is less commonly encountered, I might as well add on a quick overview of that, as it was relevant to the forum post. In simple terms, the DataWorkspace is what you use when dealing with data in Lightswitch, and one is created for you in the view model. However, when working in the screen’s code-behind, you don't have one, which is why the error message shown at the top appears. If you need to access data from an event handler, you’ll probably need to grab your own DataWorkspace.

In my original case (which is the same as Steve’s), I was trying to create a new entity. The entities that Lightswitch creates from your database have a parameterless constructor that uses the ambient DataWorkspace, meaning the one that Lightswitch creates for you (ambient = hanging around counting dead flies, waiting for you to do something that it knows about). If you are in a view model, then this works fine, which is why you generally don’t have to worry about DataWorkspaces, as most of your code should be written in the view model.

However, sometimes you need to do this stuff in event handlers, and you don’t have an ambient DataWorkspace hanging around. In this case, you need to use another entity constructor that takes a DataWorkspace as a parameter. In my case, this meant doing this...

  new InvoiceAction(this.DataWorkspace.MyAppData.InvoiceActions);

All this does is grab hold of a DataWorkspace explicitly, and pass it to the entity’s constructor. Once you know about this, the error message at the start of this article makes more sense, but when you first encounter it, your eyes start to glaze over, and you wonder why there are so many dead flies behind your monitor (Fred has been too busy dealing with your errors to clean them out).

I hope this has been helpful to someone! If you have any comments, or would like to hear how Fred and Jim are getting on, please click the “Comments” link below and let me know.

Thursday, November 29, 2012 3:51:00 PM (GMT Standard Time, UTC+00:00)
# Tuesday, October 30, 2012

This one amused me...

protected void On_DayLoad(object sender, EventArgs e) {
  Beverage coffee = new Beverage("coffee");
  coffee.Add(Beverage.Sweetener.Sugar);
  coffee.Cream = false;
  Cup mug = new Cup();
  mug.Add(coffee);
  Me.Consume(mug);
  mug.Dispose();
}

Of course, you could argue that the hard-coded string in the Beverage class constructor is bad design, but it’s only a joke eh?

This one is an old one, but I liked the variation of answer...

Question: How many programmers does it take to change a light bulb?

Answer 1: None, it's a hardware issue

Answer 2: A properly designed light bulb object would inherit a Change() method from a generic base Lighting class, so all you'd have to do is send a light bulb change message

Tuesday, October 30, 2012 2:00:00 PM (GMT Standard Time, UTC+00:00)

Why a toolbar control?

A month ago, I posted an article showing how to create a custom toolbar for a Lightswitch application. At the time, I thought that this was so easy that there was little point in creating a control extension for it. However, the more I thought about it, the more I realised that whilst it’s very easy for an experienced programmer, it wouldn’t be quite so easy for someone with less experience. Furthermore, easy as it was, it still requires you to build the toolbar yourself and write the code.

This niggled me enough to have a go at creating a control extension to implement the toolbar. Along the way I learned some new Lightswitch tricks, and ended up with a control that’s even easier to use than writing your own!

You’ll need the latest version (1.15, published today on the Visual Studio Gallery) of the control extension to follow along. Imagine we have a Lightswitch application that maintains contact details for ferrets (as you do!). We have a list and details screen that displays the ferrets’ information, and want to add a toolbar above the details side to allow the user to change the selected ferret’s name. This is a contrived example, but was the best I could think up on the spur of the moment and with little sleep! For a more realistic example of why you might want a toolbar, see my previous blog post.

Here’s a screen shot of what we’re aiming for...

A static toolbar in action

Regular readers will recognise the dear elephant that has graced this blog several times. The other icons come from my usual source, www.findicons.com, although I recently discovered some great free icons at www.proicons.com. One of the good things about that site is that the icons are organised into themes, rather than being a random collection of individual icons like www.findicons.com. Anyway, you can see that the toolbar above has five buttons, three with just an image, one with an image and text, and one with just text. The Pixata Static Toolbar control allows you to choose how your button will look (including completely restyling it if you want, see later).

Using the toolbar control

To use the control, click the “Add A Data Item” button on the Lightswitch designer window, and add a new Local Property. As with all the static controls, this is merely to get around the Lightswitch limitation of requiring all controls to be bound to something, so you can leave it as a string (uncheck the “Is Required” checkbox) and name it anything you like. I tend to call mine StaticProperty, as it helps me remember what it is when looking at the designer, but you can call it anything you like.

Drag this property onto the designer wherever you want the toolbar to appear, and change the control type to Pixata Static Toolbar control...

Choosing the Pixata Static Toolbar control

Setting the button properties

Have a look in the Properties panel. The first three properties apply to all buttons in the toolbar. The “Image width” and “Image height” properties set the size of the images to be displayed on the buttons. For simplicity (and to make the toolbar look nicer), you have to set the one width and one height, and this will be used for every button. Next you can set the margin for the button. The default is “0,0,5,0” which gives 5 pixels space to the right of each button, so they don’t squash right up next to each other. You change this to whatever you like, but the default setting is probably all you’ll ever need.

After that, you’ll see five groups of properties that look like this...

The properties for a button

Unfortunately, I don’t think there is any way to group these visually, but you’ll see that there are five sets of identical properties. The checkbox specifies if the button is displayed or not. The toolbar allows you up to five buttons, but also allows you less by clearing the checkboxes. If you want more than five buttons in a toolbar, just add two of them.

The link below the checkbox allows you to select the image that will be used for the button. The text for the button is shown next. If you just want an image on the button (like in the 1st, 3rd and 5th buttons in the screen shot at the top of this post), then leave this property blank. If you choose an image and enter text, you’ll end up with both, like the 2nd button in the screen shot earlier. If you just enter text and don’t choose an image, then you’ll end up with a text-only button, like the 4th button above. This last option isn’t that exciting, as you can do this in Lightswitch alone.

The tooltip is the text that will be displayed when your mouse hovers over the button. In the screen shot earlier, my mouse (which you can’t see) was hovering over the 2nd button, and the tooltip text is displayed.

The “Tag text” property allows you to set the tag of the button to a string. The purpose of this will be explained below.

Handling the button click event

The only other thing you need to do is to handle the event when a button is clicked. This is the only place you need to write code to use this control. Click the “Write code” button in the screen designer, and choose the ScreenName_InitializeDataWorkspace event. The first thing you need to do is add the following line at the top of the file...

using PixataCustomControls.Presentation.Controls;

Then add the following lines inside the event handler that was created for you...

partial void FerretsListDetail_InitializeDataWorkspace(List<IDataService> saveChangesTo) {
  var toolbar1 = this.FindControl("FerretToolbar");
  toolbar1.ControlAvailable += (S, E) => {
    StaticToolbar stb = ((StaticToolbar)E.Control);
    stb.ButtonClick += new System.EventHandler<StaticToolbarEventArgs>(FerretToolbar_BtnClick);
  };
}

My toolbar is called FerretToolbar, so unless you’ve chosen the same name (welcome fellow ferret fan!), you’ll need to change that to match what you chose. By default, Lightswitch will name it after your static property, but you can change this to something more meaningful.

When the ControlAvailable event fires, the code above grabs the toolbar control (which I’ve stored in a local variable called stb), and then subscribes to the ButtonClick event, which will be fired whenever someone clicks one of the toolbar buttons. To make life easier, I only added one event instead of five.

All you need now is the event handler. Here is a sample...

void FerretToolbar_BtnClick(object sender, StaticToolbarEventArgs e) {
  FerretsSet.SelectedItem.Name = e.TagText;
}

This simple example simply updates the selected ferret’s name to the tag text of the button that was clicked. If your application requires similar behaviour for each button, then using the tag text is a great way to simplify the code. This is similar to the way I inserted standard text in the previous blog post. If you don’t set the tag text, then this will set the name to the empty string.

If you want to have your buttons do distinct things, then this isn’t necessarily the best way to go, as the tag text doesn’t give enough flexibility. In this case, you can just check which button was clicked, and branch appropriately. The ButtonClick event takes a StaticToolbarEventArgs object, that contains the tag text (as shown above), as well as the number of the button. Note that the buttons are numbered one to five and NOT zero to four, as I thought that was too confusing for the general user.

Here is a sample of how to handle this case...

void FerretToolbar_BtnClick(object sender, StaticToolbarEventArgs e) {
  switch (e.ButtonNumber) {
    case 1:
      DoButtonOneStuff();
      break;
    case 2:
      DoButtonTwoStuff();
      break;
  }
}

I’ve only shown two cases here to save some space, but it would work the same if you use more buttons.

Modifying the buttons as much as you like

I know that there are people out there who will immediately ask me if they can get hold of the individual buttons, so they can customise them like crazy! Well, I’m one step ahead of you! The control exposes an indexer, which allows you to get the actual buttons on the toolbar. Once you have the toolbar itself (as I did in the FerretsListDetail_InitializeDataWorkspace event handler earlier), you can just do this...

stb[1].Content = "New Text For Button #1";

This rather pointless example shows you how to set the Content for the button to a plain string. As mentioned above, you can do this from the Properties panel without needing code, or you can use a regular Lightswitch button (generated when you drag a method onto the designer surface). However, the point here is that stb[1] is the actual button, so you can do anything to it that you could do to a normal button, including replacing the Content with something of your own invention. I can’t think of any suitably weird example, so I’ll leave that to you dear reader!

Note again that the buttons are numbered from one to five, so if you attempt to access button zero, you will get an IndexOutOfRangeException exception.

One small niggle

One thing I found was that if you want a toolbar with more than five buttons, and you use two of my static toolbar controls next to each other, Lightswitch helpfully adds three pixels of blank space between them. It does this to all controls, so they don’t get all squashed up, but in this case, it is not desirable. I contemplated hacking around to try and remove these three pixels, but decided it wasn’t worth the effort, especially as most toolbars will not have more than five buttons that need to be together. You generally find that toolbars have their buttons in smaller groups, with a vertical divider between the groups. You can do this easily by using several static toolbar controls, and separating them with the Pixata Vertical Divider control. You’ll need to add something between the divider and the next toolbar, so that Lightswitch adds its three pixels. The easiest way to do this is use a Pixata Spacer Control, with the width set to zero.. .

The 1st and 4th controls in that Columns Layout are two static toolbars. The second control is the vertical divider (width set to 1), and the 3rd control is a spacer whose width is zero.

The result of this looks like this...

I hope you find this new control useful. As usual, if you have any comments or questions, please leave them on the Visual Studio Gallery page.

Update 24th Sept ‘12

For those using VB.NET, here is a sample of an entire screen code that does pretty much the same as the code above.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Imports PixataCustomControls.Presentation.Controls

Namespace LightSwitchApplication

Public Class Customers

Private Sub Customers_InitializeDataWorkspace(saveChangesTo As System.Collections.Generic.List(Of Microsoft.LightSwitch.IDataService))
  AddHandler Me.FindControl("FerretToolbar").ControlAvailable, AddressOf FerretToolbar_ControlAvailable
End Sub

Private Sub FerretToolbar_ControlAvailable(sender As Object, e As ControlAvailableEventArgs)
  Dim FerretToolbar As StaticToolbar = TryCast(e.Control, StaticToolbar)
  AddHandler FerretToolbar.ButtonClick, AddressOf FerretToolbar_ButtonClick
  ' Set properties here if you like
End Sub

Private Sub FerretToolbar_ButtonClick(sender As Object, e As StaticToolbarEventArgs)
  Customers1.SelectedItem.Name = e.TagText
End Sub

End Class

End Namespace
Sunday, June 3, 2012 2:48:00 PM (GMT Daylight Time, UTC+01:00)