I’ve created a few short videos, covering some introductory material – still may be useful for some… The audio quality is not the best possible, but should be fairly understandable.

All the videos are in Hebrew (sorry, non-Hebrew speakers! You can still watch me type code samples, it may have some value)

The videos are:

Introduction to C# 5.0 asynchronous programming

Introduction to the Managed Extensibility Framework (MEF)

Understanding XAML (Part 1)

Understanding XAML (Part 2)

They are also available (or will be shortly) on the Hi-Tech TV web site.

Enjoy!

• Read more
• No comments

The famous WPF/Silverlight Grid class is the typical workhorse of a complex UI. Able to imitate any of the other standard container panels (except WarpPanel, which is too weird even for a Grid…), its elements are placed in specific cells using the Grid.Row and Grid.Column attached properties (with optional spanning available through Grid.ColumnSpan and Grid.RowSpan).

There is a less known cousin to the Grid – the UniformGrid (does not exist in Silverlight out of the box), that does not seem to be too useful at first glance. Curiously enough, it does not derive from Grid, but rather directly from Panel.

A UniformGrid is just that – a grid with all its cells in uniform size. The number of cells is determined by the Columns and Rows properties, as opposed to the more complex (and flexible) arrangement in a regular Grid using RowDefinitions and ColumnDefinitions.

Adding elements to a UniformGrid automatically places the element in the next cell (moving from left to right and then top to bottom). This arrangement may seem limiting – and in normal circumstances it is.

The real power of the UniformGrid is in its ability to be an ItemsPanel of an ItemsControl. A regular Grid just can’t cut it. The problem is, the ItemsControl simply calls the Children.Add method on its items’ panel. Since a regular Grid requires setting Grid.Row and Grid.Column on every element (otherwise they all end up in cell 0,0), this won’t work as expected in data binding scenarios. A UniformGrid, on the other end, automatically places each subsequent element in the next cell, making it perfect for data binding to a collection.

Here’s an example for a simple Tic Tac Toe game:

        <ItemsControl Grid.Row="1" x:Name="_board" MouseLeftButtonUp="OnClickBoard">
            <ItemsControl.ItemsPanel>
                <ItemsPanelTemplate>
                    <UniformGrid Columns="3" Rows="3" />
                </ItemsPanelTemplate>
            </ItemsControl.ItemsPanel>
            <ItemsControl.ItemTemplate>
                <DataTemplate>
                    <Border BorderBrush="Blue" Margin="3" BorderThickness="2">
                        <Grid>
                            <TextBlock x:Name="_tb" Text="{Binding}" FontSize="40" 
                                       VerticalAlignment="Center" HorizontalAlignment="Center" />
                        </Grid>
                    </Border>
                    <DataTemplate.Triggers>
                        <DataTrigger Binding="{Binding}" Value="Empty">
                            <Setter Property="Opacity" Value="0" TargetName="_tb" />
                        </DataTrigger>
                    </DataTemplate.Triggers>
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>

The ItemsControl is bound using code like so:

_game = new TicTacToeGame();
_board.ItemsSource = _game.Board;

Here’s how that looks:

The Board property is an ObservableCollection<CellType> where CellType is Empty, X or O (an enum).

The UniformGrid makes binding and displaying in such scenarios pretty convenient.

The source code is attached.

TicTacToe.zip

• Read more
• 3 comment(s)

When working with a WinForms or a WPF application in .NET, a console application is not created by default, so statements involving the Console class normally go to the trash. The console window may be a useful debugging aid, printing anything that may be important during runtime.

Fortunately, there is a way to get it back. Actually, there are two ways. The first, the “hard way” is to create the console explicitly using the native AllocConsole function:

[DllImport("kernel32")]
private static extern void AllocConsole();

All that’s left is to call this function in Main, or the Application class’ constructor.

The other way (the easy way) is to simply go to Project Properties and (in the Application tab) change the output type to a console application. That’s it!

To use the console, you can call the usual Console.Write(Line), but there may be a better way, to integrate with the default tracing mechanism of .NET using the Trace class (and friends). The Trace object writes to a collection of TraceListeners, which can be configured easily in the config file.

The following example adds the console as a trace listener:

<configuration>
  <system.diagnostics>
    <trace>
      <listeners>
        <add name="console" type="System.Diagnostics.ConsoleTraceListener" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

Now every call to Trace.Write(Line) will also trace to the console (and the default trace listener – the debugger output window – if the debugger is active. Can be captured by the DebugView tool).

• Read more
• 4 comment(s)