This is a simplistic solution to load user controls by late binding with the use of reflection. Imagine that you have a main WPF application and need to load AddIns or Plugins to this application after the application has been started. This means early binding will not work, ie adding a reference to the project before compiling. To solve this reflection can be useful and a simple example with source code will be shown. This solution only supports load and does not support unload. What is presented is mereley a proof-of concept to load a .dll from an applicatin without having to reference that dll when the application was built.

Three projects will be used in this example, the application and two AddIns. Start with creating the AddIns. In this case I created two projects of type User Control Library and named them AddIn1 and AddIn2. For this example the AddIns are only a label:

<UserControl x:Class=”AddIn1.AddIn”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
Height=”Auto” Width=”Auto”>
<Label Content=”AddIn1″ FontSize=”20″ Foreground=”Red”/>
</UserControl>

<UserControl x:Class=”AddIn1.AddIn”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
Height=”Auto” Width=”Auto”>
<Label Content=”AddIn1″ FontSize=”20″ Foreground=”Red”/>
</UserControl>

To both this projec I added a class called WPFAddIn with only one method:

public class WPFAddIn
{
public FrameworkElement GetAddInUI()
{
return new AddIn();
}
}

Thats all needed for the plugin. Now to the main application. Create and WPF Application, I named it to WPFLateBinding. In the window make a simple layout with a StackPanel and two buttons.

<Window x:Class=”WPFLateBinding.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″>
<StackPanel Name=”_stackPanel”>
<StackPanel Orientation=”Horizontal”>
<Button Content=”Load AddIn1″ Click=”Button_Click”/>
<Button Content=”Load AddIn2″ Click=”Button_Click_1″/>
</StackPanel>
</StackPanel>
</Window>

Implement the EventHandlers for the button clicks:

private void Button_Click(object sender, RoutedEventArgs e)
{
loadAddIn(@”..\..\..\AddIn1\bin\Debug\AddIn1.dll”);
}

private void Button_Click_1(object sender, RoutedEventArgs e)
{
loadAddIn(@”..\..\..\AddIn2\bin\Debug\AddIn2.dll”);
}

As you can see a loadAddIn method is being called with a path to a compiled dll. The implementation of loadAddIn looks like this:

void loadAddIn(string path)
{
MethodInfo mi;
object result = null;

try
{
Assembly assemblyInstance = Assembly.LoadFrom(path);

Type[] types = assemblyInstance.GetTypes();
foreach (Type t in types)
{
mi = t.GetMethod(“GetAddInUI”);
if (mi != null)
{
string typeName = t.FullName;
object lateBoundObj = assemblyInstance.CreateInstance(typeName);
result = t.InvokeMember(“GetAddInUI”, BindingFlags.Public | BindingFlags.InvokeMethod | BindingFlags.Instance, null, lateBoundObj, null);
break;
}
}

_stackPanel.Children.Add(result as FrameworkElement);
}
catch (Exception e)
{
Console.WriteLine(e);
}
}

The loadAddIn method opens the dll and performs a search for the “GetAddInUI” method in the types of the assembly. If found the method is invoked and the result is casted to a FrameworkElement.

While going through the design phase of our new in-house enterprise-level application, one of the topics our team touched upon is whether we should look into WPF. I think the idea was compeling and besides, it’s always nice to jump into something new. I had some time to mess around with WPF and i have to admit, the things that i don’t like about it are piling up by the hour.

WPF roadmap

My biggest question is whether WPF will actually replace WinForms. The lack of definite answer from Microsoft leads me to think that this is probably what’s going to happen when the framework matures. I have read a few blogs where some folks suggest otherwise. However, I just don’t see a reason why you would consider supporting WinForms when you have something much superior and flexible to offer. Aside from that, what’s stopping Microsoft from screwing a major part of their community developing in WinForms. They’ve already done it with Web Service Enhancements and its support in Visual Studio 2008. VS 2008 itself was pretty much abandoned after the first service pack release, and according to this, we can all suck a big fat one because Microsoft sees more value in getting your benjamins for new licenses of VS 2010 than actually releasing a new service pack for potentially one of the worst Visual Studio releases. (if it isn’t the worst, it’s probably up there with the shitty ones)

Flashy design or back to WinForms?

There is no doubt that WPF is a good enhancement to software design process. It’s a powerful framework and with power comes complexity. Unfortunately, managing that complexity comes at a significant expense. You can either screw around with the XML markup that generates trendy UI or you can get Expression Blend and screw with it, which adds another layer of complexity on its own. Your other option is, of course, to hire a good UI designer who’s not only familiar with all of the tools necessary to work with the framework, but who can also do some design, animation programming and etc. I don’t know what the statistic is for software companies hiring graphics designers, but i have yet to work for one which actually did. Besides, considering how new this technology is, I can only wonder how difficult it would be to fill such a position.

Working with Expression Blend

My exposure with Blend was very limited and frustrating. I’ve had the chance to work with Expression Blend 2, which appears to be out of date since the version 3 is out already. I’m sure a lot of folks worked with Photoshop and its intuitive UI. It seemed much of Blend interface is borrowed from Photoshop, which at first was a great indicator. However, working with the application revealed that it is a new charlie foxtrot from Microsoft. I played around with a few features and tried what i thought was going to be an easy task – adding background image to a rectangle. I spent an hour attempting to do this and got absolutely nowhere. As was explained in this article, performing such a simple task is completely counter-intuitive. At this point, i had absolutely no doubt in my mind that this wasn’t going to go anywhere, and off this hunk of shit went from my machine. What a complete waste of time that was.

A good WPF showcase project?

I find it really difficult to actually get my hands on one. StockTrader is a good candidate for a sample WPF project to look at. However, most of its focus is on service-oriented software design, not so much on WPF. And it shows, as the project is just scratching the surface when it comes to WPF. Otherwise, i can’t recall any showcase projects with decent UI implementation. I wonder why Microsoft hasn’t stepped in and released a real-world WPF solution, just like they did Oxite for ASP.NET MVC. The lack of any decent material on WPF and Blend is also pretty astounding for such a hype both caused. All i was able to find was bits and pieces of information, nothing concrete like design patterns, specific design guidelines and such. It just seems like everything’s up in the air at this point.

I’m not even sure how to conclude this. I would probably still consider utilizing WPF for new solutions. You still have your standard set of controls and everything to get you started. The unfortunate thing is that you’ll probably not going to benefit much from the main features of the framework, but you’ll have to migrate at some point. Might as well do it now and hope that MS enhances their tools a little as the whole thing matures.

Il est très courant en WPF que l’on doivent redéfinir le rendu des composants de base afin d’avoir une interface plus ergonomique pour l’utilisateur.

Prenons par exemple le cas d’une ListBox de personne, qui ressemblerait à peu près à ça :

Pour ce code XAML :

<ListBox ItemsSource="{Binding}">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <TextBlock>
                <TextBlock.Text>
                    <MultiBinding StringFormat="{}{0} {1}">
                        <Binding Path="FirstName" />
                        <Binding Path="LastName" />
                    </MultiBinding>
                </TextBlock.Text>
            </TextBlock>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

Maintenant, on va supposer que le client veut que tous les Items soit placé, non pas l’un en dessous de l’autre, mais disperser au niveau de la fenêtre selon différents critères. Il voudrait donc que l’interface ressemble à quelque chose de ce genre :

Donc là on voit clairement que selon les besoins des spécifications, les items de la liste ne sont ni vraiment ordonnées, mais plus vraisemblablement placé au hasard dans l’application. Cependant on a tout de même bien affaire à une liste d’élément.

Nous avons donc plusieurs choix qui s’offre à nous, le premier est de créer un Canvas, ou l’on ajoute les éléments 1 à 1 en code behind. Ce choix peut être pas trop mal, mais va de ce fait nécessité un peu de code, et la maintenance sur cet ajout de composant peut rapidement devenir compliqué, surtout si vous voulez “binder” les différents champs.

Notre deuxième choix serait donc de customiser la ListBox, ce qui permettrait uniquement grâce au binding de placer nos Items, sans nous embêter, et de plus nous pourrons rendre ça plus facilement dynamique. Donc, pour cela, on va commencer par faire des tests, on va changer la propriété ItemsPanelTemplate, pour y mettre un Canvas.

        <ListBox ItemsSource="{Binding}">
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <Canvas />
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
            <ListBox.ItemTemplate>

Puis après, nous allons ajouter deux propriétés à notre objet Personne afin d’y spécifier les coordonnées X et Y de l’item dans la ListBox, notons qu’on pourrait ajouter ces propriétés d’une autre manière, mais là ce n’est qu’une démonstration….

Ceci fait, nous allons maintenant lier les positions aux propriétés Canvas.Top et Canvas.Left de notre TextBlock. Alors déjà premier petit problème, l’intellisense ne nous fournit pas ces propriétés dans notre DataTemplate, on peut donc se dire que cela provient d’un bug de l’Intellisense, après tout Visual Studio 2008 et le XAML n’apporte pas beaucoup d’aide là ou il le faudrait. Donc on va tout de même le taper et voir si ça compile.

                <DataTemplate>
                    <TextBlock Canvas.Top="{Binding Pos.Y}" Canvas.Left="{Binding Pos.X}">
                        <TextBlock.Text>

Et là c’est magique, Visual Studio compile correctement le projet, ne signale aucune erreur, n’annonce pas de problème de binding dans la sortie. Mais par contre l’application quand à elle ne marche pas comme on le souhaite, car on obtient ceci :

On voit ici très bien qu’il ne prend pas en compte nos coordonnées, on se dit maintenant que Visual Studio avait peut être raison de ne pas nous proposer les propriétés Canvas.Left et Canvas.Top sur notre TextBlock.

Après un peu de réflexion, on se dit qu’il faudrait essayer de définir un style à notre Item, et là encore, la ListBox, est bien équipé pour ça, avec sa propriété ItemContainerStyle.

            <ListBox.ItemContainerStyle>
                <Style>
                    <Setter Property="Canvas.Left" Value="{Binding Pos.X}" />
                    <Setter Property="Canvas.Top" Value="{Binding Pos.Y}" />
                </Style>
            </ListBox.ItemContainerStyle>

On enlève maintenant nos propriétés de la TextBlock , vu que visiblement elles ne fonctionnent pas, et puis on relance notre application. On obtient donc ainsi notre joli fenêtre :

Alors, effectivement comme ça on peut ne pas trop voir l’utilité de repositionner chacun des Items, en fait c’est parce que pour mon projet Imagine Cup, je suis en train de réaliser une ListBox ou les items sont disposés sous forme de cercle. Mais je ne vous dévoile pas tout !

D’ailleurs j’en profite pour passer une annonce, si vous connaissez un étudiant sur Paris qui est intéressé par les technologies comme le XAML, ainsi que l’ergonomie et le design d’application, notre équipe recherche quelqu’un, vous pouvez donc m’envoyer un mail à wilfried.woivre[at]gmail.com.

Now that I know that myapp.xaml holds the key to the application’s startup, I want to look closer at where the AppStartup method lives: myapp.xaml.cs.

This file is a complete C# file leveraging the .NET Framework Class Library. The first thing I notice is the file uses six namespaces all ultimately from the System namespace. System is clearly one of the most important namespaces of any C# project. From the descriptions over at the .NET Framework Reference, my first take on their usage is

• System is required for the most fundamental aspects of the application like class and struct types (eg. the Object class from which all other classes are derived
• System.Windows is required because this will be a WPF application
• System.Data has no apparent usage at first glance
• System.Xml is required to parse XAML files since they are XML files
• System.Configuration is required to configure the application (i’m guessing configuration is detailed in the XAML files)
• System.Windows.Media is required for drawing stuff (like the alarm clock image) and producing sound (I don’t think this alarm clock actually has an alarm though)

You don’t actually have to give everything a namespace but it seems to be a best practice guideline since Microsoft always does it. Here, the application is given the namespace Microsoft.Samples.WinFX.AlarmClock. So far, I don’t think they are necessary unless you plan to write your own library (compiling as DLLs).

On to the meat: public partial class MyApp : Application.
Of course, the application class should be “public” but what’s with “partial”? In Part 1, I mentioned that the build process will automagically create an entry point method so the application knows how to start, I’m guessing the build process also creates a class based on myapp.xaml which gets put into separate file from the compiled myapp.xaml.cs in which case “partial” is needed to specify this is just part of the class definition. I gathered as much from Building a WPF Application

In addition, a language-specific code file is generated for every XAML file. For example, for a Page1.xaml page in a Visual Basic project, a Page1.g.vb is generated; for a Page1.xaml page in a C# project, a Page1.g.cs is generated. The “.g” in the file name indicates the file is generated code that has a partial class declaration for the top-level element of the markup file (such as Page or Window). The class is declared with the partial modifier in C# (Extends in Visual Basic) to indicate there is another declaration for the class elsewhere, usually in the code-behind file Page1.xaml.cs.

The main application class is given the name “MyApp” and inherits from Application which comes from the System.Windows namespace. The Application class “Encapsulates a Windows Presentation Foundation (WPF) application.” That makes sense, Alarm Clock Sample is a WPF application.

Finally, the application process is run and, on startup, the AppStartup method is called. I already talked about the prototype so let’s look at the body:

• TraditionalClock tradClock = new TraditionalClock(); There’s an object TraditionalClock defined somewhere (probably in traditionalclock.xaml and traditionalclock.xaml.cs)
• tradClock.Opacity = .6f; Clearly, this will set the Opacity of the object (which, by now, I’m assuming consists of at least the image of the clock and hands)
• tradClock.Show(); Most likely renders the clock to the screen.

The other method, void clockWindow_Closed(object sender, EventArgs e) is pretty straightforward now that I understand the AppStartup method. It is my understanding that every method triggered by an event will have an “object sender” and “EventArgs e” argument where EventArgs may be different depending on the event. The body of this method merely contains Application.Current.Shutdown(0); which speaks for itself but the .NET Framework Reference gives some more input: The Current property is thread safe and allows access to the application’s instance in the current AppDomain (kind of like a sandbox for each executing application) from any thread.

The Calculator Demo I visited previously is far too complex for now so I’ve decided to try to understand the Alarm Clock Sample instead. It is a much simpler application though still written for WPF and as such is using XAML.

Upon downloading the source, I first built the project. This time, there were no problems. The build succeeded and I opened the app. Just as I suspected, it was very simple–just a picture of an old school alarm clock with animated hands, opacity set as to not be opaque, and draggable whilst showing the outline of an outrageously large rectangle. I was surprised, however, that it was taking 50% of my processing power which, on a dual core processor, means it’s maxing out probably because of some infinite loop.

Ok, so now that I see what the program is all about, it’s time to dive into the code. I went straight for myapp.xaml to find Startup. Thanks to the WPF Application Management Overview, I know now that this is used to define the handler for the Application.Startup Event which “Occurs when the Run method of the Application object is called.“

I now understand the syntax of void AppStartup(object sender, StartupEventArgs e) in app.xaml.cs.

• void means this method will not return anything (basic knowledge from any strongly typed programming language)
• AppStartup defines the name of the method which will be called on activation of the Application.Startup Event.
• object sender is a reference to the object which raised the event
• StartupEventArgs e gives access to the properties of the event in question

Cool, but the Startup event “Occurs when the Run method of the Application object is called.” Doesn’t that mean the application needs a “Run method”? Usually the Run method gets put into the Main method but it doesn’t exist in the Alarm Clock Sample just as it didn’t exist in the Calculator Demo. No such luck finding Run either. The answer lies in the background. What we don’t see in the application nor during the build process is that the entry point Main and the all-important Run get inserted automagically. I felt lucky searching for “wpf main()” and I was. Someone asked How can I provide my own Main() method in my WPF application? (I’ll have to look further into that website sometime) and the answer was

At compile-time WPF generates the real entry point method using the classic static void Main() method signature in C#, or Public Shared Sub Main() in VB.NET. Inside the Main() method WPF creates an instance of one of your classes which derive from System.Windows.Application, and calls the blocking Run() method on this Application-derived class which keeps the process “alive”.

Perfect. Now, I can figure out how the app is actually put together rather than how it can exist in the first place.

Microsoft выпустила Fishbowl — opensource клиент для Facebook с богатым функционалом. Fishbowl представлется собой клиентское приложение, которое дает удобный и быстрый доступ ко всем функциям Facebook.

Приложение Fishbowl может работать в двух режимах: стандартном и минимизированном. Во втором случае на экране появляется небольшое окошко с последними обновлениями статусов ваших друзей.

В наличии тесная интеграция с Windows 7 Aero: отображение обновлений, быстрый доступ к функциям через JumpLists, Aero Preview.

Просмотр загруженных фотографий удобен:

Кроме того, Fishbowl поддерживает проверку орфографии, пока только на английском языке.

via www.ithinkdiff.com/fishbowl-desktop-facebook-client-optimized-for-windows-7/

After reading through a bunch of the .Net Framework Class Library, I noticed they have some samples for download. I really wanted to dive into GUI programming so I checked out the Calculator Demo.

I knew it would be fairly complicated from the description but when I opened the source, I was taken aback by the complexity. As the comments pointed out, it wouldn’t compile correctly in the command line because of “missing files” but I still couldn’t get that to work so I fired up the behemoth Visual Studio and, it’s true, “this example doesn’t build unless…”.

The calculator was running, I played around to experience the features, then went back to the source code. From the tutorials I had looked at previously, I knew every C# program needed to have a static Main() method as a starting point. I searched every file for “Main” but to no avail. I searched the internet for C# applications without Main() but to no avail.

Since the easy path to understanding wasn’t working out, I stretched my arms and began looking through each source file for the starting point of the application. Eventually, I found Startup="AppStartingUp" in app.xaml which quickly led me to void AppStartingUp(object sender, StartupEventArgs e) in app.xaml.cs (conveniently enough).

This discovery didn’t help me understand what was happening but it did lead me to search for xaml which happens to stand for “Extensible Application Markup Language” and, like C# and .NET, was created by Microsoft and looks to be just as complicated.

Of course, since I had never heard of it before, I realized I would need to find a primer on XAML. My First XAML Application is a perfect introduction. As it turns out, the C# language isn’t too difficult but .NET is a tremendously large framework which is going to force me to learn a lot more than just C#. I mean, XAML is just part of the Windows Presentation Foundation!

We have already discuss the usage of Visual Brush and see how we can use it to make a text reflection. This time we are going to make a visual brush to fill the geometrical shape with control. We will do a binding of Visual Brush with UIElement, just like we use to do data binding with other UIElement.

  1: <Ellipse Grid.Row="1" Margin="5">

  2: 	<Ellipse.Fill>

  3: 		<VisualBrush Visual="{Binding ElementName=list}"/>

  4: 	</Ellipse.Fill>

  5: </Ellipse>

  6: 

Here is a class diagram of Brush class.

Here is a complete program to fill the ellipse with a lix box usingVisual Brush. 

  1: <Window x:Class="VisualBrush.Window1"

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

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

  4:     Title="Visual Brush" Height="400" Width="400">

  5:     <Grid>

  6:         <Grid.RowDefinitions>

  7:             <RowDefinition/>

  8:             <RowDefinition/>

  9:         </Grid.RowDefinitions>

 10:

 11:         <ListBox Grid.Row="0" Name="list" Margin="5" Background="AliceBlue" >

 12:             <ListBox.ItemTemplate>

 13:                 <DataTemplate>

 14:                     <TextBlock FontSize="14" Foreground="Navy" Text="{Binding}"/>

 15:                 </DataTemplate>

 16:             </ListBox.ItemTemplate>

 17:         </ListBox>

 18:         <Ellipse Grid.Row="1" Margin="5">

 19:             <Ellipse.Fill>

 20:                 <VisualBrush Visual="{Binding ElementName=list}"/>

 21:             </Ellipse.Fill>

 22:         </Ellipse>

 23:     </Grid>

 24: </Window>

 25: 

Here is C# code of this program.

  1: using System;

  2: using System.Collections.Generic;

  3: using System.Linq;

  4: using System.Text;

  5: using System.Windows;

  6: using System.Windows.Controls;

  7: using System.Windows.Data;

  8: using System.Windows.Documents;

  9: using System.Windows.Input;

 10: using System.Windows.Media;

 11: using System.Windows.Media.Imaging;

 12: using System.Windows.Navigation;

 13: using System.Windows.Shapes;

 14:

 15: namespace VisualBrush

 16: {

 17:     /// <summary>

 18:     /// Interaction logic for Window1.xaml

 19:     /// </summary>

 20:     public partial class Window1 : Window

 21:     {

 22:         public Window1()

 23:         {

 24:             InitializeComponent();

 25:

 26:             List<String> stateList = new List<string>();

 27:

 28:             stateList.Add("Maryland");

 29:             stateList.Add("California");

 30:             stateList.Add("Virginia");

 31:             stateList.Add("Washington");

 32:             stateList.Add("New York");

 33:             stateList.Add("Nevada");

 34:             stateList.Add("Florida");

 35:             stateList.Add("Arizona");

 36:

 37:             list.ItemsSource = stateList;

 38:         }

 39:     }

 40: }

 41: 

This is the output of this program.

After a few busy weeks (Mondays and Thursdays) our workshop has reached the end. I hope that guys who had attended this workshop had some joy and got some knowledge/experience with these technologies

I’d be glad to repeat it, but there are some other interesting areas to cover, so keep reading my blog to find out when’s the next workshop.

Best wishes!

By default when you add a WCF Service reference in WPF, it does not give async functions. If your application needs async features, while adding a reference to the service, lookout for a ‘Advanced’ button on Add service reference window at bottom right corner. On clicking on that button, a new window appears. There is a checkbox called ‘Generate Asynchronous Operations’. Hit Ok and you are done!

Simple isn’t it

Today i got some free time and decided to play with MSIL and did little experiment with it. I did one small experiment and try to make one simple application of WPF in MSIL.

  1: .assembly Wpfil{}

  2:

  3: .method static void start ()

  4: {

  5:     .entrypoint

  6:     .maxstack 8

  7:

  8: 	ldstr "Hello World from MSIL"

  9: 	call valuetype [PresentationFramework]System.Windows.MessageBoxResult [PresentationFramework]

 10: System.Windows.MessageBox::Show(class System.String)

 11: 	pop

 12: 	ret

 13: }

 14: 

The output of this program is one message box with “Hello World from MSIL”. But this message box is from WPF not a windows standard message box.

But if we want to display a window in WPF then we have to create object of at least two class Application and Window class. Here is a MSIL code to create object of Window and Application class.

  1: newobj     instance void [PresentationFramework]System.Windows.Window::.ctor()

  2: stloc.0

  3:

  4: newobj     instance void [PresentationFramework]System.Windows.Application::.ctor()

  5: stloc.1

  6: 

But first we have to set the attribute of program as a single threaded. We can do it with the following MSIL statement.

  1: .custom instance void [mscorlib]System.STAThreadAttribute::.ctor()

Here is a complete MSIL code of the program.

  1: .assembly Wpfil{}

  2:

  3: .method static void start ()

  4: {

  5:     .entrypoint

  6: 	.custom instance void [mscorlib]System.STAThreadAttribute::.ctor()

  7:     .maxstack 8

  8:

  9: 	.locals init ([0] class [PresentationFramework]System.Windows.Window win,

 10: 		[1] class [PresentationFramework]System.Windows.Application app)

 11:

 12: 	newobj     instance void [PresentationFramework]System.Windows.Window::.ctor()

 13: 	stloc.0

 14:

 15: 	newobj     instance void [PresentationFramework]System.Windows.Application::.ctor()

 16: 	stloc.1

 17:

 18: 	ldloc.0

 19: 	ldstr "Hello World from MSIL"

 20: 	callvirt   instance void [PresentationFramework]System.Windows.Window::set_Title(string)

 21:

 22: 	ldloc.1

 23: 	ldloc.0

 24: 	callvirt   instance int32 [PresentationFramework]System.Windows.Application::Run(class [PresentationFramework]System.Windows.Window)

 25: 	pop

 26: 	ret

 27: }

 28: 

The output of this program is one window with “Hello World from MSIL” caption.

Similarly we can define other properties of the window. Here is an example toe set the width and height of the window.

  1: .assembly Wpfil{}

  2:

  3: .method static void start ()

  4: {

  5:     .entrypoint

  6: 	.custom instance void [mscorlib]System.STAThreadAttribute::.ctor()

  7:     .maxstack 8

  8:

  9: 	.locals init ([0] class [PresentationFramework]System.Windows.Window win,

 10: 		[1] class [PresentationFramework]System.Windows.Application app)

 11:

 12: 	newobj     instance void [PresentationFramework]System.Windows.Window::.ctor()

 13: 	stloc.0

 14:

 15: 	newobj     instance void [PresentationFramework]System.Windows.Application::.ctor()

 16: 	stloc.1

 17:

 18: 	ldloc.0

 19: 	ldc.r8     400

 20: 	callvirt   instance void [PresentationFramework]System.Windows.FrameworkElement::set_Width(float64)

 21:

 22: 	ldloc.0

 23: 	ldc.r8     300

 24: 	callvirt   instance void [PresentationFramework]System.Windows.FrameworkElement::set_Height(float64)

 25:

 26: 	ldloc.0

 27: 	ldstr "Hello World from MSIL"

 28: 	callvirt   instance void [PresentationFramework]System.Windows.Window::set_Title(string)

 29:

 30: 	ldloc.1

 31: 	ldloc.0

 32: 	callvirt   instance int32 [PresentationFramework]System.Windows.Application::Run(class [PresentationFramework]System.Windows.Window)

 33: 	pop

 34: 	ret

 35: }

 36: 

Here is the output of this program.

I have found that WPF and Silverlight XAML are sufficiently different to make single-sourcing difficult.

At first I did not know if it was possible at all, but I knew one thing – the differences in usage of namespaces look like something very annoying for which there must be an elegant solution.

The Problem

The first issue was with the standard controls which are in WPF 4.0 but not in Silverlight 3.0 (only in the toolkit), e.g. the Expander is declared like this in WPF,

<Expander … />

But it is declared like this in Silverlight,

… xmlns:Controls1="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit" …
<Controls1:Expander … />

What I really did not understand was that there is a similar problem when the standard controls which are in WPF 4.0 also are in Silverlight 3.0; for example, the HierarchicalDataTemplate is declared like this in WPF,

<HierarchicalDataTemplate … />

But it is declared like this in Silverlight,

… xmlns:Windows="clr-namespace:System.Windows;assembly=System.Windows.Controls" …
<Windows:HierarchicalDataTemplate … />

Clearly the rules for defaulting and declaring namespaces are different.

The First Solution

I searched the Internet and found a few suggestions. One suggestion is to have two sets of name space references. This works because you are allowed to use name spaces on WPF although it is not mandatory. I did not like it because it still meant maintaining different files since XAML does not allow #IFDEF-like constructs.

My colleague David Anson found a surprisingly simple solution which he describes in a blog post (see the last bullet in the notes at the end of the post). The main idea is to subclass standard controls, effectively bringing them into the same namespace across Silverlight and WPF.

It looks like magic – and ReSharper also claims that this is not valid – but it works. Well, it almost works.

The Problem with the First Solution

So far I have found one problem with the first solution – the HierarchicalDataTemplate.

If I used David’s trick,

public class HierarchicalDataTemplate : System.Windows.HierarchicalDataTemplate { }

xmlns:Std="clr-namespace:Microsoft.Dynamics.Ax.Frameworks.Controls.StandardControls"

41: <Std:HierarchicalDataTemplate x:Key="hierarchicalDataTemplate" ItemsSource="{Binding Path=Subcomponents}">
42:    <StackPanel Orientation="Horizontal">
43:        <Image Source="{Binding Path=TreeIcon}"/>
44:        <TextBlock Text="{Binding Path=Name}"/>
45:    </StackPanel>
46: </Std:HierarchicalDataTemplate>

Then it compiled in Silverlight and WPF but the StackPanel caused problems at run-time in WPF. The error was

‘StackPanel’ object cannot be added to ‘HierarchicalDataTemplate’. Object of type ‘System.Windows.Controls.StackPanel’ cannot be converted to type ‘System.Windows.FrameworkElementFactory’.  Error at object ‘System.Windows.Controls.StackPanel’ in markup file ‘Microsoft.Dynamics.Ax.Frameworks.Controls;component/singlesourcetest.xaml’ Line 42 Position 26.

It did not help to use David’s trick again and add StackPanel to the Std namespace.

This is a WPF bug. It has not been fixed in the WPF 4.0 beta I am using but I hope it will be fixed eventually in the RTM.

The Second Solution

David worked hard on this problem and got another brilliant idea; if this is a problem with WPF only then why not subclass in Silverlight only? This requires a little trick that left David "a little slimy" – see his blog post for the details – but it works. Well, it almost works.

The Problem with the Second Solution

I took the sample project from the blog post for a spin and found that it would not work if I added x:Name="myTreeview" to the TreeView in XAML. This is the error I got,

The type ‘System.Windows.Controls.TreeView’ exists in both ‘c:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Windows.Controls.dll’ and ‘e: \SharingXamlSilverlightWpf\PresentationFramework\Bin\Debug\PresentationFramework.dll’                e:\enlistments\axmain6\source\frameworks\controls\sharingxamlsilverlightwpf\sharingxamlsilverlightwpf-sl\obj\debug\mainpage.g.cs      38           42           SharingXamlSilverlightWpf-SL

Clearly there is a problem with disambiguating identical names across assemblies.

I needed to reference the name of the tree from a details view so I could not use the second solution for at least the controls that I needed to name.

But since the second solution seemed to only be needed for HierarchicalDataTemplate anyway, I am now using the first solution for everything but the HierarchicalDataTemplate.

And this works. Well, it almost works. But the remaining problems seem to be unrelated to this single-sourcing approach so I will defer blogging about it till later.

I decided to use Prism, aka Microsoft Composite Application Guidance For WPF and Silverlight.

This is very much like using a supersonic jet fighter to pop down to the local shops but its effective, not very hard and does not require you to write reams of fragile custom code. You just need to spend a bit of time getting used to Prism. Now that’s not a trivial task, but you should have covered the fundamental concepts within a working week, assuming you have some prior knowledge of Dependency Injection.

The huge advantage to you is that Prism is written by people who are much better programmers than you or I are, so the code is robust, whereas writing a custom MDI Window Manager is out of the league of most Intermediate-level developers (most of us).

Very simply, Prism allows the development of Modular Applications in which the User Interface of an application is decomposed into loosely-coupled Modules, each of which occupies a specific area on the screen, known as a Region.

No window (known in Prism as a View) can move outside the Region in which it is contained. This replicates the MDI-like behaviour you’re looking for.

Prism is also a library of Best Practices – it’s produced by the Microsoft Patterns and Practices team – so you get heaps of built-ins for free. And there’s a helpful forum where others using Prism are happy to help us newbies.

You can also have multiple windows (views) open simultaneously if you want, but this will render as a tabbed interface which is not exactly the same as MDI.

I embarked upon this approach and have been successful in producing a MDI-like app. It wasn’t too hard and I learnt heaps along the way. Go for it.

For the framework element set KeyboardNavigation.TabIndex="<number goes here>"

Simple isn’t it?

Hi,

Let us imagine a collection of Fathers which hold FirstName of fathers. Each father has a kids collection where all his kids names are stored.
The collection are displayed in a datagrid and the rows are displayed using a Listview and a gridview.

<my:DataGrid AutoGenerateColumns="False" Margin="28,39,33,21" Name="dataGrid1">············
<my:DataGrid.RowDetailsTemplate>················
<DataTemplate>····················
<ListView Name="Kids" ItemsSource="{Binding Kids}">························
<ListView.View>····························
<GridView>································
<GridViewColumn  Header="Kids" DisplayMemberBinding="{Binding Name}"/>····························
</GridView>························
</ListView.View>····················
</ListView>················
</DataTemplate>············
</my:DataGrid.RowDetailsTemplate>············
<my:DataGrid.Columns>················
<my:DataGridTextColumn Header="Father Name" Binding="{Binding FirstName}"/>············
</my:DataGrid.Columns>········
</my:DataGrid>

Now lets create some scenarios in our project in the format the details are to be displayed
Scenario1: Make the families background red where there are no kids
Scenario 2: Hide the families where the name of the father is less than 8 chars
Scenario 3: Make the font bold where the fathers name is greater than 8 chars and there are 2 kids

Make the families background red where there are no kids
Binding is very flexible in WPF you can easily bind to any of the properties available in the class. Like in this scenario we need to check if the kids count in the family is 0. For this we need to declare a style and bind our RowStyle of the grid to the defined style. Lets work on it.
Lets declare a style and name it as CheckKids and check for the kids.count condition for 0.

········
<Style x:Key="CheckKids" TargetType="{x:Type my:DataGridRow}">············
<Style.Triggers>················
<DataTrigger Binding="{Binding Kids.Count}" Value="0">····················
<Setter Property="Background" Value="Red"/>················
</DataTrigger>············
</Style.Triggers>········
</Style>

In the collection Mr.Ramiayaa has no kids so background of his row is made red.

public bool IsLengthLessThanEight
{
get { return (FirstName.Length < 8); }
}

········
<Style x:Key="FatherNameLessEightChar" TargetType="{x:Type my:DataGridRow}">············
<Style.Triggers>················
<DataTrigger Binding="{Binding IsLengthLessThanEight}" Value="True">····················
<Setter Property="Visibility" Value="Hidden"/>················
</DataTrigger>············
</Style.Triggers>········
</Style>

<Style x:Key="CheckNameAndKidsCount" TargetType="{x:Type my:DataGridRow}">············
<Style.Triggers>················
<MultiDataTrigger>····················
<MultiDataTrigger.Conditions>························
<Condition Binding="{Binding IsLengthLessThanEight}" Value="False"/>························
<Condition Binding="{Binding Kids.Count}" Value="2"/>····················
</MultiDataTrigger.Conditions>····················
<Setter Property="FontWeight" Value="Bold"/>················
</MultiDataTrigger>············
</Style.Triggers>········
</Style>