30 November 2011

Binding, and Templates, and ContentControls, oh my!

I'm working in Silverlight 4, and have been trying to get a particular binding scenario to work right. It seems to be the case that try to satisfy any one or two requirements is easy enough, but when things start piling up, Silverlight can get a bit tricky.

My requirements:

  1. I'm creating a UserControl
  2. The UserControl itself needs to work inside a template.
  3. I want to define properties on the UserControl.
  4. I want a ContentControl in the UserControl
  5. I want to define a ContentTemplate on the content control
  6. And lastly, I want this inner template to bind to properties of the UserControl

The problems:

  • I can't name the UserControl and use ElementName inside the template, because the UserControl itself is also going to be used in a template, and ElementName doesn't always behave well in that situation.
  • I can't programatically set the DataContext or Bindings within the template, because Silverlight doesn't give programatic access to a template.
  • Setting the DataContext of the UserControl or the ContentControl to the UserControl itself doesn't help, because the DataContext of a template is actually the Content property of the ContentControl.
  • I can't set the Content of the ContentControl to the UserControl itself, because this makes Silverlight hang (presumably due to an infinite recursive loop).

So here's what I've got working. It's disgusting, but seems to work.

<ContentControl x:Name="content"/>
<TextBox Text="{Binding Self.SomeValue}" />

And the code...

public partial class MyControl : UserControl
public class Indirection
public ValueEditor Self { get; set; }

public MyControl()
this.content.Content = new Indirection() { Self = this };

public static readonly DependencyProperty SomeValueProperty = ...
public string SomeValue { ... }


So the idea is to set the ContentControl.Content to a proxy object that is not the control itself, but with a reference to the control, which can then be accessed in the path of the binding.

If you know a nicer way to do this, please leave a comment!

29 November 2011

Default parameters

How disappointing! I've just started to dip a toe into C# default parameters. And they have to be compile-time constants. Sure, it makes a lot of sense, but how about allowing static readonly properties as well?

All I want is this:

// Not too much to ask for?
void MyMethod(Guid someId = Guid.Empty)

26 November 2011

Now I've noticed the whine, it's going to drive me crazy

Way back in the '80s I cut my programmers teeth on a Microbee 32k. Back on a classy green and black CRT, with an audio cassettes for permanent storage.

One of the things I remember noticing was that while playing a tune (1-bit square wave), if I held down a key on the keyboard that the frequency would drop slightly. This was presumably due to the poor 2MHz CPU having to stop counting how long it has spent on each waveform to go and service the keyboard IRQ. How quaint.

Now, as I sit at a PC that's at between three and five orders of magnitude more powerful, depending on the measure, I've just noticed an errily familiar behavior.

With my sound turn up, I hear a faint low-pitched hum even though no sound is playing. Now, whenever I move my mouse it turns into a faint high-pitched squeal. I actually get one of two high pitches depending on how fast I'm moving the mouse.

Not 100% sure what's going on here, but as they're USB powered speakers, I'm guessing that the transmission of mousing data is causing some interference on the power rail. I guess it shouldn't be surprising given that people have figured out how to capture keystrokes from EM emissions.

24 November 2011

INotifyPropertyChanged code snippet

I've never really worried about getting into Visual Studio code snippets. But I've been using INotifyPropertyChanged a lot recently, so it got me looking at them again.

Found this cool snippet by Brian Schroer for filling out properties. Here's my slightly customized version of it to suit personal taste. Thanks Brian!

Steps to intall:

  1. Save the following to NotifyProperty.snippet on your desktop1
  2. In Visual Studio go to Tools / Code Snippets Manager
  3. Press Import and locate the file
  4. Import the file into My Code Snippets

Steps to use:

  1. In the code editor, type propn then press TAB twice.
  2. Immediately type the name of the property. Press tab.
  3. Then type the .Net Type name of the property.

The code:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Description>Code snippet for property and backing field in class implementing INotifyPropertyChanged</Description>
<Author>Brian Schroer</Author>
<!-- http://geekswithblogs.net/brians/archive/2010/07/27/inotifypropertychanged-with-less-typing-using-a-code-snippet.aspx -->
<ToolTip>Property type</ToolTip>
<ToolTip>Property name</ToolTip>
<Code Language="csharp">
<![CDATA[/// <summary>
/// Gets or sets the $property$
/// </summary>
public $type$ $property$
get { return _$property$;}
if (value != _$property$)
_$property$ = value;
private $type$ _$property$;

Some VS macros I can't live without

Here's a few Visual Studio Macros that I can't live without at the moment. They're somewhat pieced together from bits I found online and customized for my needs. Thanks to whoever you are!

In order:

  • Locates the currently open file in the Solution Explorer panel.
  • Attaches debugger to a service.
  • Attaches debugger to an open Silverlight window.

(Ugh! VB - Whoever thought it was a good idea to write whole applications in this stuff?)

Imports System
Imports EnvDTE100
Imports System.Diagnostics

Public Module AttachDebugger

Public Sub LocateCurrentFileInSolutionExplorer()
' Suggest binding to: Alt+L Alt+L
End Sub

Public Sub DebugMyService()
Dim p As EnvDTE.Process

For Each p In DTE.Debugger.LocalProcesses
If p.Name.ToLower().EndsWith("myservice.exe") Then
Exit Sub
End If
MsgBox("Could not find ReadinowSvc.exe")
End Sub

Sub DebugSilverlight()
'Thanks to http://www.dllshepherd.net/2011/05/silverlight-attach-to-process-shortcut.html
Dim dbg2 As EnvDTE80.Debugger2 = DTE.Debugger
Dim trans As EnvDTE80.Transport = dbg2.Transports.Item("Default")
Dim dbgeng(1) As EnvDTE80.Engine
dbgeng(0) = trans.Engines.Item("Silverlight")

For Each process As EnvDTE80.Process2 In dbg2.GetProcesses(trans, Environment.MachineName)
If process.Name.Contains("iexplore.exe") Then
For Each program As EnvDTE.Program In process.Programs
If program.Name.Contains("Silverlight") Then
End If
End If
Catch ex As System.Exception
End Try
End Sub

End Module

15 November 2011

Binding UserControl properties in Silverlight

It seems to me that the logical thing to do in Silverlight when building some sort of composite control is to create a UserControl, expose some properties, add some controls to the user control, and bind them to those properties.

For example, a custom CoffeeMug control might want to expose MugColor and PercentFull properties. However, it's taken me quite a while to figure out how to get this to work properly.

The problem is in selecting the binding source. WCF offers the FindAncestors binding helper, which can be used to locate the user control relative to the control being bound, but Silverlight offers no counterpart.

So initially I had been using ElementName:

<UserControl x:Name="thisControl" ... >
<Rectangle x:Name="mugShape"
Background="{Binding MugColor, ElementName=thisControl}" />

This works pretty well in simple circumstances, but it wasn't working for me in DataTemplate scenarios, such as in the DataGrid. I was having similar problems with using custom controls in custom ComboBox and ListBox data templates.

Well, apparently its a known shortcoming of Silverlight. When the data template is asked to make a concrete instance, it no longer carries the necessary context information to resolve element names directly. It can however be overcome by manually specifying the binding in code.

public CoffeeMug()
this.Loaded += new new RoutedEventHandler(Control_Loaded);
void Control_Loaded(object sender, RoutedEventArgs e)
Binding binding = new Binding("MugColor");
binding.Source = this;
// remember to set binding.Mode = TwoWay if applicable
this.mugShape.SetBinding(Shape.BackgroundProperty, binding);

This guy has also hacked together a behavior to make everything much nicer in an MVVM environment as well, but I don't think I'd go to that much effort personally.

10 November 2011

Debugging immediate variables

Here's a neat Visual Studio debugging trick I just stumbled on today by accident. Sometimes, it can be very handy to be able to refer back to information from another frame in the stack, or from a previous call to the same function.

Step 1

When you're at a location of interest, use the intermediate window to declare a new variable and assign a value to it. (Remember to give it a type declaration or 'var').

// Type this into the 'Immediate' window
var tmp = data;

Step 2

Now, when you're at a completely different location, either in a different method, or even at a different calling of the same method, you can still inspect your immediate variable in the watch window.

Obviously the temp variable is not going to automatically update if the source it came from gets updated, but it can still be pretty handy sometime, for example to compare two values to see if they're the same.

Presumably we're also holding onto a reference now that would prevent it from being garbage collected, so in a large environment it might be a good idea to set the temp variable back to null when you're done with it.

What happens if you set it to a variable name that is then used at a subsequent break point? Answer: it gets blown away and replaced with the new value (and type).

9 November 2011

Interface implementation and covariance

I was a bit disappointed to discover that the following code doesn't compile in C# 4. In particular, it seems that as the 'Thing' property is only a getter on the interface, any concrete implementation should be able to return a derived type, since it can be guaranteed that anyone getting the parent type from the interface will also be able to operate on the child type.

class Thing { }

class SpecificThing : Thing { }

interface IThingContainer
Thing Thing { get; }

class SpecificThingContainer : IThingContainer
public SpecificThing Thing { get; set; }