C# Disciples

Loads of times I have been asked in forums, how do I make a GridViewColumn communicate with another in WPF. A common use case is that you have a checkbox in Column1 and you want that when the checkbox is checked something happens in Columnx.

The first obvious answer is make a property in your business object that can reflect that change. Yet some times this is strictly UI and you don’t want to clutter your business object with UI code.

One solution could be to use the power of DataBinding. Lets start by explaining in very high level, how a GridView works. So a GridView is simply a Logical entity. To make it sound more familiar we can say that a GridViewColumn is like Grid ColumnDefinition / RowDefinition. It’s an entity that will effect how the parent (in our case the ListView) will look. A GridView will construct a GridViewHeaderRowPresenter and a GridViewRowPresenter that will construct the header of the ListView and the ListView rows. Because the GridView does this, we can do a trick with databinding that will enable us to make Inter-Column communication possible.

Basically the idea is to bind the CheckBox’s IsChecked property to the Tag property of it’s GridViewRowPresenter with a OneWayToSource binding. This will make sure that when the user check/unchecks the Checkbox the IsChecked state is stored in the GridViewRowPresenter. something like this

   1: <GridViewColumn Header="checkbox here" Width="100">

   2:     <GridViewColumn.CellTemplate>

   3:         <DataTemplate>

   4:             <CheckBox IsChecked="{Binding RelativeSource={RelativeSource AncestorType={x:Type GridViewRowPresenter}}, Path=Tag, Mode=OneWayToSource}"/>

   5:         </DataTemplate>

   6:     </GridViewColumn.CellTemplate>

   7: </GridViewColumn>

Now that we have that in place other columns can easily become aware of the state changes by doing a DataTrigger on the GridViewRowPresenter like so

   1: <GridViewColumn Header="text here" Width="100">

   2:     <GridViewColumn.CellTemplate>

   3:         <DataTemplate>

   4:             <TextBlock Text="{Binding}" Foreground="Red" x:Name="text"/>

   5:             <DataTemplate.Triggers>

   6:                 <DataTrigger Binding="{Binding RelativeSource={RelativeSource AncestorType={x:Type GridViewRowPresenter}}, Path=Tag}" Value="True">

   7:                     <Setter TargetName="text" Property="Foreground" Value="Green"/>

   8:                 </DataTrigger>

   9:             </DataTemplate.Triggers>

  10:         </DataTemplate>

  11:     </GridViewColumn.CellTemplate>

  12: </GridViewColumn>

and that’s basically it…

Thank you WPF!!!! We love you

Download demo Application

Lately I’ve been working on a project at work and the application was performing pretty well. The CPU Usage was below 2% and I was quite happy with it. Then I decided to add a simple animation that continues executing forever… the results 15% CPU consumption … I was amazed at how much CPU was being wasted. Yet I am a stubborn guy and if I want an animation to execute forever, I will do it no matter what….

I started researching and I found out that WPF animations by default try to serve a 60 frames per second… Which is quite a lot!!! After having a chat with my friend ( and role model ) DR.WPF, it was all clear. (Thanks Dr for all the help you give me !!!)

So in order to reduce the frame rate per second (thus reducing CPU usage), all you need to do is to override the property meta data of the Dependency property Timeline.DesiredFrameRateProperty…. So basically all you need is 1 line of code (I usually put this code on startup of the application)

   1: Timeline.DesiredFrameRateProperty.OverrideMetadata(

   2:             typeof(Timeline),

   3:             new FrameworkPropertyMetadata { DefaultValue = 20 }

   4:             );

Yep, that’s it… Amazing but true…. I managed to make an application that was consuming 15% CPU to consume 2% CPU….

With regards to what frame rate should you use, I would leave that to you…. This depends on how smooth you want your animations to perform… Yet for me 20 is working quite fine…

Hope this helps

In WPF Dialogs are quite different from Windows Forms. The behavior is still the same i.e when you have a Dialog opened (by calling the ShowDialog() method) the user must close the dialog in order to use the Window that opened the Dialog Window. The difference is the way you handle the Dialog Result and also how to set Dialog Results.

Let’s say that you created a Window in Windows Forms and you have a Button. You can set the DialogResult property of the button so that when the user click on that button the Dialog ends with the Dialog Result that you have set. (also if the user clicks the exit button of the Dialog the DialogResult would be a Cancel). The code to handle the DialogResult in Windows Forms would look like this

   1: DialogResult result = new Form1().ShowDialog();

   2: if (result == DialogResult.OK)

   3:     MessageBox.Show("User clicked OK");

   4: else if (result == DialogResult.Cancel)

   5:     MessageBox.Show("User clicked Cancel");

In the WPF this is different. There is no DialogResult property on controls and also the ShowDialog does not return a DialogResult instead it returns a Nullable<bool>.

So to handle a DialogResult after calling the ShowDialog() in WPF your code would look like this

   1: MyDialog dialog = new MyDialog();

   2: dialog.ShowDialog();

   3:

   4: if (dialog.DialogResult.HasValue && dialog.DialogResult.Value)

   5:     MessageBox.Show("User clicked OK");

   6: else

   7:     MessageBox.Show("User clicked Cancel");

ShowDialog can return True which is equivalent to DialogResult.Ok or False which is equivalent to DialogResult.Cancel.

So let’s have a look at how you can create a Dialog in WPF and set the DialogResult of the Dialog. We can do this by setting a property on the Window called DialogResult. Once you set this property on the Window the Window will automatically close and the ShowDialog methods returns the result that you have set in the DialogResult property.

If you want to have a “Cancel” Button for your Dialog you can use the IsCancel property and set this to true. When the user clicks the button the DialogResult will be set to false and the Dialog will close. This will also allow the user to click ESC to cancel the dialog ( which is something that every user would expect from a dialog). Please note that if you have more than one button with the IsCancel = “True” the ESC does not work as expected instead the focus will be given to the first button that has the IsCancel = “True”. The XAML for this button would look like this

   1: <Button Width="100" Content="Cancel" IsCancel="True"/>

If you want to have an “Ok” button you can set the IsDefault property. This property will NOT set the DialogResult to true for you, instead it will allow the user to click “Enter” and the Click event handler of the button is automatically called (so as such it doesn’t really have to do with Dialogs, it is just more useful when you are using Dialogs because users would expect such a behavior). You must code the event handler (and obviously register the handler to the click event) yourself and set the DialogResult to true. Something like this

   1: private void ButtonOkClick(object sender, RoutedEventArgs e)

   2: {

   3:     DialogResult = true;

   4: }

That’s basically it. For more information you might want to have a look at the MSDN documentation on this here.

Download Sample Dialog application

I just had a look at some new features of a fantastic tool NDepend. NDepend is a superb tool that one can use to get source code statistics and what not…. This tool is very powerful and fairly easy to use. One can use the CQL (which is an SQL like language ) to query for statistics over your code.

As I said some new features have been added that makes this tool even more cool and powerful! Basically now you can get Test coverage over your code as well Super!!!!

Have a look yourself ….

One of my favorite blogs on WPF topics is Mike Hillbergs blog. This guy is amazing! His last post is a classic for me. He really managed to write a post that is so easy to read on fairly complex concept to understand. I suggest that you have a look at his brilliant blog…

here it is, Logical and visual trees in WPF

One thing that I love about scripting languages is that, to test some code you do not need to create a sample application and run that application. You can simple run the interpreter, write the code you want to test and you get the results… With compiled languages this is harder to achieve.

So whenever I need to test something, like for example let’s say I want to test what the .ToString() would give me for a DateTime object I need to create a sample application, write my code, compile and run… Quite cumbersome to test some simple code!

Enter TestDriven.Net

TestDriven.Net is a brilliant tool! This tool is a VS plugin to run Unit tests. Long story short, to run a unit test you need to right click in the Test method and Select “Run Test(s)” (shown in the image below). You also have the option to run the test with the debugger. This feature enables you to have breakpoints in your code and step through your test (to do this you must select the “Test with Debugger” option from the context menu).

Now how does TestDriven.Net fit in this article?

TestDriven.Net can be used to not only run tests but also normal code (at the end of the data, a test is still C# code). So basically if you are writing a method and you want to run some code all you have to do is to put a breakpoint inside you method, right click and select Test with Debugger and voila you are now running the code you wanted without the need to start the whole application or even worse create a sample application!

Once you are in debug mode, you can use the Immediate window to write whatever code you want to test and it will get evaluated there and then. You can also change the values of the variables that are in context from the Immediate window. What could be cooler than this

Also for those that love Intellisense (well I don’t know who doesn’t !) Immediate Window also offers this feature for us developers

Another way how to achieve this functionality is by pressing F10 instead of F5 in Visual Studio. Basically when you press F10 VS will run the Application but start debugging immediately. In this way you can use the immediate window to try out the code that you wish to execute there and then

So there you have it….

This trick that I just showed, makes my life much easier and I hope that it will help you as well

Have loads of coding fun….

“C# my Name, CLR my Passion” << Marlon Grech the C# Disciple

I installed VS2008 SP1 because for me there are far too many COOL changes, and I could not wait till I get my hands on them

Yet as a side effect my Blend stopped working…. Now I do not use blend so much but still I think that it is a very powerful tool and sometimes it is really handy… I found a blog post that saved my Blend…

Here you go have a look and fix yours

http://blogs.msdn.com/expression/archive/2008/04/18/vs2008sp1.aspx

One of the most beautiful controls in blendables (in my opinion) is the CameraPanel. This control lets you put your element in a 3d space and then move them around by moving the camera…. and yes you can apply animations and data binding to the camera properties because it uses Dependency properties for it’s CameraX, CameraY and CameraZ…. So basically you can do something like this in no time….

What I also like about the CameraPanel is that the child elements that you put in are still interactive (THIS IS A BIG PLUS). For example in the demo I’ve put a couple of buttons and a textbox to show how the user can still use the controls normally.

In my demo the user can click the button and the camera will animate the CameraZ property and yes the effect is super cool!!!!

Guess what this is not really 3D
CameraPanel is actually a 2D panel that simply gives the impression of 3D by applying transforms to its children…. If this is cool then have a look at the 3D Mix from blendables and get impressed

Download the Demo Application….

Have you heard? The guys at Redmond impressed the world once again! .Net 3.5 SP1 is now Beta…. If you didn’t already, I would suggest that you read this brilliant post from Tim Sneath to get more info on what’s new in WPF.

Today, I wanted to experiment a bit with the new Effects that were included in the SP1 Beta. These effects are the same as the BitmapEffects that were previously in WPF. One can also say that these are the replacement for the BitmapEffects. Why? Simple. BitmapEffect are slow, these are NOT! BitmapEffects are fully software rendered while the new Effects take advantage of the machine’s GPU. Well this is not exactly right there are instances where this does not apply…

• When the graphics card being run on does not support PixelShader 2.0 or above. This is becoming more and more rare, but is definitely still out there.
• When the WPF application is being remoted over Remote Desktop or Terminal Server or some other kind of mirror driver.
• When the WPF application is in a mode where software rendering is required – such as rendering to a RenderTargetBitmap, or printing.
  (this was taken from this post, well copies and pasted if I might. How would I know such a thing after all )

Ok, so what can you do with these effects? something like this as starters….

In the sample application I used the DropShadowEffect and the BlurEffect, and then I combined the 2 together. One of the cool things with these effects is that the properties are Dependency properties i.e we can databind the properties values.

It is very easy to apply an effect to an element. All you have to do is to set the Effect property like so

<Button Content="Shadow" Width="100" Height="100">

    <Button.Effect>

        <DropShadowEffect Color="Red"

                          BlurRadius="50"

                          ShadowDepth="50"

                          Direction="30"

                          />

    </Button.Effect>

</Button>

One thing that is worth mentioning is that you cannot apply more than one effect to a UIElement. Yet we can workaround this by having a wrapper element(ex: Border) and set the other Effect on the wrapper element. Something like this

<Border Grid.Column="2" Grid.RowSpan="2" Width="100" Height="100">

    <Border.Effect>

        <BlurEffect Radius="10" />

    </Border.Effect>

    <Button Content="Both">

        <Button.Effect>

            <DropShadowEffect Color="Red"

                          BlurRadius="30"

                          ShadowDepth="30"

                          Direction="90"

                          />

        </Button.Effect>

    </Button>

</Border>

Cool stuff….

[Update]

Dr.WPF pointed out that WPF SP1 will upconvert the legacy BitmapEffects so that those effects run on the new accelerated pipeline. This will happen wherever possible. It will not happen if the effect is placed within a BitmapEffectGroup because the new pipeline supports only single effects.

For example, if a single BlurBitmapEffect has been applied to an element, SP1 will automatically use a BlurEffect on the element instead so that the blur is hardware accelerated (This upconversion will happen as long as the Radius value is between 0 and some acceptable value). Similarly, a single DropShadowBitmapEffect will be treated as a DropShadowEffect in SP1 whenever possible (This upconversion will happen as long as the Noise property is 0). Certain effects from the old pipeline will never be accelerated in the new pipeline. These include BevelBitmapEffect, OuterGlowBitmapEffect, and EmbossBitmapEffect.

Thanks Dr. We would be lost without you.

Download the Sample application I prepared and play around with these new cool features (Please note that you need .Net 3.5 SP1 installed on your machine)

I would suggest to read this series of posts to get to know effects better.

Have load of fun!

Identity Mine are simple amazing… I just downloaded a sample application demonstrating some new features of Blendables Layout Mix and I am impressed… It is super COOL!!!

You must try it!!!!