DCSIMG
October 2009 - Posts - Pavel's Blog
Sign in | Join | Help

Pavel's Blog

Pavel is a software guy that is interested in almost everything
software related... way too much for too little time

October 2009 - Posts

Open House on C# 4.0 (Take 2)

Published at Oct 29 2009, 11:05 AM by pavely

Yesterday, I delivered a session titled “What’s new in C# 4.0?” after a session by Guy Burstein on “First look at Visual Studio 2010”.

Thank you all for attending. I apologise for not using all the feedbacks to select winners for the books – sorry, guys! I’ll pay attention next time (probably lack of food).

Some notes that came up during the session:

1. The misbehavior on the DynamicXmlElement class was due to a small oversight: I wrote this code when only one element existed:

case 1:

   result = elements.First();

   break;

which returns the element as is (which is an XElement, not what we want). It should have been:

case 1:

   result = new DynamicXmlElement(elements.First());

   break;

So it continues to be a DynamicXmlElement object. Again, lack of food.

2. The other question I left somewhat open, is regarding caching in the ExpandoObject example. Well, no caching is possible – no special layer there, the code must run each time and do the right thing.

The code samples will be available soon in the usual location as Guy described.

The Return (Appearance) of the Complex Type

Published at Oct 27 2009, 05:13 PM by pavely

Early in the ads for .NET 4.0, there were rumours about two types dealing with numeric stuff, BigInteger and Complex. In the Beta 1 phase, BigInteger has appeared (I’ve briefly blogged about it), but Complex was nowhere to be found.

With the advent of .NET 4.0 Beta 2, I was happy to find the emergence of the Complex type in the System.Numerics namespace (and these numeric types have been moved to their own System.Numerics.Dll assembly).

Complex is, of course, represents a complex number, with a Real part and an Imaginary part. It hosts all the usual expected properties and methods, including operator overloading and conversions.

One mishap, I believe, is the existence of a Magnitude property, returning the length of the complex number as measured from the origin, but no MagnitudeSquared property, which is an optimization – as sometimes this is what is needed and the overhead of performing a square root for the Magnitude property is unnecessary (Magnitude is calculated with the super famous pythagorean theorem, requiring a costly square root operation).

Hopefully, this property will be added in the .NET 4.0 RTM.

Local Kernel Debugging and LiveKd Update

Published at Oct 27 2009, 10:13 AM by pavely

Local kernel debugging is the ability to view kernel data structures in a live system (i.e. not connecting to a target system through a null cable modem or USB or other alternatives), and is supported since Windows XP. This is a great way to explore windows on its darker side (the kernel and related subsystems) with all its mysteries and secrets.

With Windows XP, starting local kernel debugging is pretty easy. Just fire up WinDbg (or kd for that matter), select from the menu File->Kernel Debug, navigate to the “Local” tab, click OK and start exploring.

In Windows Vista and up, trying to do the same thing produces the following message box:

“---------------------------
WinDbg:6.11.0001.404 AMD64
---------------------------
The system does not support local kernel debugging.

Local kernel debugging requires Windows XP, Administrative
privileges, and is not supported by WOW64.
Only a single local kernel debugging session can run at a time.
Local kernel debugging is disabled by default in Windows Vista, you must run 'bcdedit -debug on' and reboot to enable it.”

The bold section is the important part. On Vista and up (not just Vista, as may be suggested by the error message), this is disabled by default, and requires change in the Boot Configuration Database (BCD) and reboot. Doesn’t seem to difficult to do; however, setting this option disables the ability to do user mode debugging (e.g. with Visual Studio)… not nice.

The life saver here is Mark Russinovich from the famous SysInternals site and tools (now part of Microsoft). He wrote the livekd tool, that simulates a “blue screen” and creates a dump file, then opens it with your favourite kernel debugger (WinDbg or kd). For example, issuing Livekd –w (assuming WinDbg is in the default search path, or livekd is copied to the Debugging Tools For Windows folder and you’re running with admin privileges), this launches WinDbg and allows local kernel debugging.

Livekd was not working properly on newer systems (x64) but finally a new version was released, fixing that issue, allowing local kernel debugging on x64 systems on Vista and up.

WPF Gotcha: Default Value for a Dependency Property

Published at Oct 13 2009, 10:52 AM by pavely

When defining dependency properties in a WPF (e.g. in a user control or custom control), you can supply a default value for that property. However, if you’re not careful, you’ll get a nasty exception at runtime, with no obvious cause.

For example, consider this simple dependency property:

public double SomeLength {

   get { return (double)GetValue(SomeLengthProperty); }

   set { SetValue(SomeLengthProperty, value); }

}

 

public static readonly DependencyProperty SomeLengthProperty =

    DependencyProperty.Register("SomeLength", typeof(double),

    typeof(SomeControl), new UIPropertyMetadata(0));

When running the application hosting the control declaring this property, you’ll get a nasty XamlParseException. Looking at the InnerException, you’ll see something like:

{"Exception has been thrown by the target of an invocation."}

Great. Probably some reflection exception. Let’s look at its InnerException:

{"The type initializer for 'CustomControls.SomeControl' threw an exception."}

That’s a bit more helpful. It must be the DependencyProperty.Register method (called from the static constructor a.k.a. type initializer).

So, what’s going on here? Experienced WPF developers may spot this immediately. The problem is the default value of 0. What’s wrong with that? Can’t a double be zero? It can, but what’s missing is the value zero in a double look: 0.0 or (double)0.

Why is this happening? Simply because the argument Register expects is of type object. Passing a value type causes boxing. No surprise here. But when unboxing occurs – an exception is triggered, because a 0 (int) cannot be unboxed to a double without an intermediate cast (which, of course, is not supplied, as everything is too dynamic for that).

So, the moral of the story is: keep your default values with the exact type declared in the dependency property.

How to Kill Visual Studio 2008 Elegantly

Published at Oct 12 2009, 09:39 PM by pavely

Here’s an elegant (in my opinion) way to kill Visual Studio 2008 immediately without leaving any trace.

Here’s what you need to do:

1. Open up VS 2008 and create a new project of type C# WPF Application.

2. Open Window1.xaml and make sure you get a split view of XAML and preview.

3. The top level layout panel is a Grid (by default). Add two rows, and in one place a button. Also name the window (e.g. “win”). The markup should be something like this:

<Window x:Class="WpfApplication3.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Window1" Height="300" Width="300" x:Name="win">

    <Grid>

        <Grid.RowDefinitions>

            <RowDefinition />

            <RowDefinition />

        </Grid.RowDefinitions>

        <Button Content="Click me if you can!" FontSize="20" />

    </Grid>

</Window>

You should see the button filling the first row of the grid. Now for the fun part:

Add a Rectangle to the second row of the grid and set its fill property to use a VisualBrush binded to the window itself. Should be something like:

<Rectangle Grid.Row="1">

  <Rectangle.Fill>

     <VisualBrush Visual=“{Binding ElementName=win}" />

  </Rectangle.Fill>

</Rectangle>

As soon as you close that tag on the VisualBrush – BAM! VS disappears…

What happened here?

The VisualBrush used the window to paint the rectangle, but that means the window has changed again, so the rectangle needs to repaint and so on and so forth… I guess the poor WPF designer just couldn’t handle it…

And some people say WPF is not fun…

For all you debuggers out there, you’ve got a classic case of adplus –crash and a good dump debugging with WinDbg. Enjoy!