January 2009 - Mike Taulty's Blog

Crikey. This is a “first” for me – I came across this Wrox Press  book; and 3 of the 4 guys on the front cover are from the UK Microsoft development consulting team where I used to work. I sometimes pick up a book and know an author on the front cover but never quite as many as this :-) That’s Jonathan Chris Salvador I’ve not read it yet, I’m currently wading through Joe Duffy’s “Concurrent Programming on Windows” and if you’ve seen that book you’ll know that I’ve got my work cut out as it’s a pretty weighty book but it’s looking pretty good at this point.

I’ve taken the application that I last mentioned here and I’ve been working on it a little more. I’m not quite where I want to be just yet but I thought I’d walk through it a little and share the code. The application runs up like this; and it immediately tries to connect to the Local Live Operating Environment ( it depends on a Local Live Operating Environment ( LOE ) and will fail if you don’t have one ). It pulls the user id from that Local LOE and offers a chance to log in but you can skip it if you like as it’s only needed for Contacts which have to come from the Cloud LOE as the Live Framework doesn’t make them available from the Local LOE yet. Either way, it then shows something like this; one that UI is present I can drag and drop single photos or multiple photos from the desktop to the UI as in; It’s not possible to see the drop location on the screen capture above but it’s over the window on the left where I’m about to drop the 3 selected image files. On the right is a Virtual PC where I have a Windows...

If I was a plumber then I guess if I hit a situation where I’d put in place a big heating system and a bunch of pipework and I then suddenly thought; Wait a minute, I’ve just spotted a much better way of doing this! then I doubt that my next thought would be to rip out all the work that I’ve done and do it all again. But, if I spend hours and hours writing some code and then suddenly think; Wait a minute, I’ve just spotted a much better way of doing this! then it feels great to delete all the work I’ve done, re-do it all again and end up with something more “elegant”. Is it just because plumbing involves something physical or is there something more going on?

Or, perhaps a better title would be; “ Why it’s better to debug with the Threads window visible” I puzzled over something in a debugger for about 5 minutes the other day so I thought I’d share. I had some WPF code where I had a static class in which I wanted to share a common Image which is sort of a “default image” if the class instance itself can’t find the right image to use. So, in pseudo-code it was something like this; class MyClass() { static MyClass() { image = new Image(); // ... } static Image image; } and that Image then goes on to be used elsewhere. Whenever I was running this code, I was getting the familiar “You’re using the UI widget from the wrong thread” exception and I was puzzled because I thought I’d taken some care to try and not do that and I couldn’t figure out which widget it was that was complaining. The call-stack soon showed that it was the Image above but I was really struggling to see how I’d touched the Image from anything other than my UI thread. A bit more debugging showed that...

Blogging this in order that I remember in the future that I have been around this “loop” many times and that this code; int x = 1; Action a = new Action( ( ) => { x++; }); a( ); Console.WriteLine( x ); prints a value of 2 whereas this code; int x = 1; Action< int > a = new Action< int >( ( i) => { i++; }); a( x ); Console.WriteLine( x ); prints a value of 1 and that means that this code; struct MyStruct { public void Set() { flag = true ; } public void Print() { Console.WriteLine(flag); } public bool flag; } class Program { static void Main( string [] args) { MyStruct myStruct = new MyStruct(); Action action = new Action ( () => { myStruct.Set(); }); action(); myStruct.Print(); } } prints a value of true whereas this code; struct MyStruct { public void Set() { flag = true ; } public void Print() { Console.WriteLine(flag); } public bool flag; } class Program { static void Main( string [] args) { MyStruct myStruct = new MyStruct(); Action<MyStruct> action = new Action<MyStruct> ...

This previous post had me thinking that the WPF application that I built across these posts; Live Framework SDK - More Steps Live Framework SDK - Having a Single MeshObject Live Framework SDK - Adding a Silverlight MEWA would start to improve if I offered the opportunity to "invite others" to shared groups of photographs. So, I re-worked the code. There were a couple of things that I came across whilst doing it; It's a bit painful that you can't do everything whilst created to the Local LOE. I wanted to write 100% of my code against the Local LOE but, because you can't get a list of Contacts from the Local LOE right now it means that you have to connect to the Cloud LOE to get them. Additionally, as far as I could tell you also need to use the Cloud LOE to send a user an invitation to share a MeshObject. I don't think you can do that with the Local LOE even if you already have gathered Contact information from the Cloud LOE. That was my finding, anyway. Mappings. I'm still not 100% sure about Mappings, MeshObjects...

Following on from this previous post , the WPF and Silverlight code that I've been running tries to access a MeshObject ( containing a DataFeed of photos ) that the code itself creates at initialisation time. What I wasn't sure about at all was how that'd work if I wanted to make the same data available to another person altogether. As it stands, my WPF code runs up and does; Check local mesh for "photos" MeshObject. If not present, check cloud mesh for the same. If not present, create it. If I want to share my photos with lots of other users of the same application then is that what I want? All my users will end up with their own MeshObjects with their own photos and none of them will ever see each other. So...I set about trying to figure out what the "shared data story" is. There's a sample in the walkthroughs called MeshageBoard ( no, really :-) ) which helps quite a lot with this in that it shows the way in which one user can send invitations to another. In order to experiment with this, I decided that it...