When that happens, errors are logged to the Event Viewer, but they are not that helpful – for a change.

To avoid that error, there is a couple of ways. First of all, delete the .suo file in your solution folder. Deleting that file will do no harm to your solutions, as it only stores user-specific information, such as what are your opened files, which directories in Solution Explorer are collapsed or not, etc.

That usually works. However, not always, specially with .xaml files. If VS2008 insists in closing after deleting .suo, next time you open the .xaml file, simply press ESC repetitively, the way maniacs do. That will avoid the design view to be loaded – which apparently breaks VS2008. If you are successful in not seeing VS2008 to close again, you can close your file and re-open it. Hopefully.

What if Visual Studio still closes? Good luck, my friend.

Say that you have a Phone class that contains three properties: CountryCode, AreaCode and Number. The DataContext for your Window contains a property of type Phone, and you want to print that object information in a pre-formatted way defined at the XAML file. The desired format is something like +1 55 55555555 (plus sign, followed by CountryCode, followed by a space, followed by AreaCode, followed by a space, followed by Number).

So instead of creating a property to hold the pre-formatted string at your class side, you just want to define it at XAML level.

Take the code below as an example:

<TextBlock>
	<TextBlock.Text>
		<MultiBinding StringFormat="+{0} {1} {2}">
			<Binding Path="Phone.CountryCode" />
			<Binding Path="Phone.AreaCode" />
			<Binding Path="Phone.Number" />
		</MultiBinding>
	</TextBlock.Text>
</TextBlock>

That will just do the trick for you!

However, we have some considerations to pay attention at. First of all:

<MultiBinding StringFormat="+{0} {1} {2}">

That line just works because of that trailing plus sign. If you were to use no plus sign (or any other prefixing string) at all and just display CountryCode directly, then you need a small tweak:

<MultiBinding StringFormat="{}{0} {1} {2}">

That’s the {} just before {0} parameter.

Furthermore, there are some nice attributes to add to the Binding element. For instance, if the value of your DataContext Phone object can’t be retrieved in design-time, you might see {DependencyProperty.UnsetValue} displayed on your design screen. TargetNullValue and FallbackValue can be added to fix that.

<TextBlock>
	<TextBlock.Text>
		<MultiBinding StringFormat="+{0} {1} {2}">
			<Binding Path="Phone.CountryCode" TargetNullValue="--" FallbackValue="??" />
			<Binding Path="Phone.AreaCode" TargetNullValue="--" FallbackValue="??" />
			<Binding Path="Phone.Number" TargetNullValue="--------" FallbackValue="????????" />
		</MultiBinding>
	</TextBlock.Text>
</TextBlock>

The first one is the substitution for null values, while the value of the second one is returned when no value can be found (such as when the bound property is not initialized in design-time). Just take care as that works on runtime as well!

Just some tricks particularly interesting during MVVM development. I hope it can be of some help!

I am the Baker

I bake the cake

You’re the decorator and you decorate

You take the credit

While I slave away

I mixed, I made, I baked!

You can check the lyrics here.

I was working on unit tests and then a question came to me – why comparing objects by value is not provided out-of-the-box by the .NET Framework? We all (should) know that by default, comparing objects leads to a reference comparison, unless of course you override Equals() or implement operator == on your class.

But what if I want to compare two objects from a class provided by the Framework? That would be quite handy specially for unit tests. While we have System.Object.Equals() and System.Object.ReferenceEquals() working the very same way – reference comparison – we don’t find something like System.Object.ValueEquals().

Then I started having a discussion with a friend and colleague of mine the reasons for such functionality not existing in .NET.

Although I agree that the default option should be reference comparison, I don’t see any technical limitations for not having that implemented – Reflection could be the way to do it, going recursively down each property and checking if their values are equal.

So why not? Is it something related to the theory of object orientation or was it a mere technical decision?

Let’s take one of the classical examples of OO lessons: a Car class. In a Car, you have properties such as Color, Model, Category, etc. In real life, when two cars come out of production line, while you can’t say they are the same car, one would have no problem identifying they were built by the same method. Just compare each of their properties and you will end up knowing they are not the same car, but they share the same properties and were built the same way. They don’t share a reference equality, but value equality.

As far as I am concerned, OO does not provide a specific way or method to apply the property-by-property comparison, but there isn’t a prohibition on doing that as well.

However, providing such functionality could be an expensive trade-off, since gigantic objects with collections with millions of items could be compared. It would be possible, but sometimes not practical. But then not providing that for the developer’s discretion, or at least providing ways to ensure it could be safely used? Doesn’t seems right to me.

From my point of view, such functionality could be very useful and there is no true restriction that should be applied for having something like that provided by the Framework. As I said, my opinion is that not providing it is a technical decision, and not a philosophical restriction imposed by OO theory.

What do you think? I’d be glad to listen to other opinions!

When creating a custom ActivityValidator, you might receive a compilation error from the newly created validator, even when the custom Activity it is targeted against is not in use yet.

But how come? Let’s take a look at the example below:

[ActivityValidator(typeof(MyCustomValidator))]
public partial class MyCustomActivity : Activity
{
    public static DependencyProperty PriceProperty = DependencyProperty.Register("Price", typeof(float), typeof(MyCustomActivity));

    [DescriptionAttribute("Price")]
    [CategoryAttribute("Price Category")]
    [BrowsableAttribute(true)]
    [DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)]
    public float Price
    {
        get
        {
            return ((float)(base.GetValue(MyCustomActivity.PriceProperty)));
        }
        set
        {
            base.SetValue(MyCustomActivity.PriceProperty, value);
        }
    }

	public MyCustomActivity()
	{
		InitializeComponent();
	}
}

public class MyCustomValidator : ActivityValidator
{
    public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
    {
        MyCustomActivity myCustomActivity = obj as MyCustomActivity;
        ValidationErrorCollection errors = base.Validate(manager, obj);

        if (myCustomActivity == null)
        {
            throw new ArgumentException("MyCustomValidator can only be used to validate MyCustomActivity instances.", "obj");
        }

        if (myCustomActivity.Price <= 0)
        {
            errors.Add(new ValidationError("'Price' must be greater than zero.", 1));
        }

        return errors;
    }
}

In the example above, when you build the project you will receive an error such as

Error 1 Activity 'MyCustomActivity' validation failed: 'Price' must be greater than zero.

Well, that is not nice. You are not even using MyCustomActivity yet!

The reason for that is simple: validators are run during runtime, but also during build time! To avoid the error, we simply check if the custom activity is in use. How? Take a peak:

public class MyCustomValidator : ActivityValidator
{
    public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
    {
        MyCustomActivity myCustomActivity = obj as MyCustomActivity;
        ValidationErrorCollection errors = base.Validate(manager, obj);

        if (myCustomActivity == null)
        {
            throw new ArgumentException("MyCustomValidator can only be used to validate MyCustomActivity instances.", "obj");
        }

        if (myCustomActivity.Parent != null)
        {
            if (myCustomActivity.Price <= 0)
            {
                errors.Add(new ValidationError("'Price' must be greater than zero.", 1));
            }
        }

        return errors;
    }
}

As you can see, all we did was checking if the activity parent is not null (line 13).

Try to build now, no error will be triggered. Then drop MyCustomActivity to a workflow, don't fill in Price and build again. The error is now there, correctly returned!

Well, that was it... No black magic but surely resourceful! I hope it helps!

And then you find him. An horrendous, terrible, dreadful enemy. His name: AG_E_PARSER_UNKNOWN_TYPE.

You start looking for reasons of such an error, but all you find is despair. No hints, no clues, you start loosing your temper – and possibly your hair. You curse the framework for not supplying you with enough information: just a plain AG_E_PARSER_UNKNOWN_TYPE on your xaml file. Googling does not help you much, as few have faced that horrible vilain.

Fear not, friend, as I have found him myself, and I am going to share the secrets of some of his weak spots. Explore them, and I hope you defeat him the way I did.

Jokes apart, that was an error that took me a while to figure it out. Everything happened when I was creating user controls that were related to each other by their parent class. And impressively I run into two different situations in the same task that lead me to AG_E_PARSER_UNKNOWN_TYPE.

My solution was structured as follows:

using System;
using System.ComponentModel;

namespace MySolution
{
    public abstract class MyBaseClass : UserControl
    {
    }

    public partial class MyClass1 : MyBaseClass
    {
    }

    public partial class MyClass2 : MyBaseClass
    {
    }
}

First error in the intended code above: the MyBaseClass derivating from UserControl can’t be declared abstract. I know, it is a pain in case you want to create an abstract method within – you won’t be able to do that at all. Try a workaround like creating virtual methods throwing a NotImplementedException, and then overriding it with the real implementation.

The other situation I found that error in was related to listeners and the user control constructor. I’m not entirely sure why that happens, but if you register for a listener on the constructor class (or call any method registering it from the constructor) of your user control, you might have a chance to encounter the might evil AG_E_PARSER_UNKNOWN_ERROR is.

Also, a collegue pointed out for me a blog post with some explanations to AG_E_PARSER_UNKNOWN_ERROR and other Silverlight hell minions alike. Despite being related to Silverlight 1.1 alpha, I found the list to be trully helpful. I wish I had found that one before, the struggle would be much smaller!

Say that you want to present a message to your user while he waits an asynchronous call to be completed. However, given the nature of the call, you can’t control how long it will take to complete, and thus that message may be just a quick blink in the screen. But what if you still want that message to be readable, even when the call answers almost instantaneously?

Using System.Threading.Thread.Sleep() is not a good option, since it will hold the current thread – that is, the UI thread. And the user will be probably pissed off for having his browser frozen by the application.

The solution: BackgroundWorker and Dispatcher classes.

System.ComponentModel.BackgroundWorker (MSDN link) is a class that allows instructions to be run on a dedicated thread, with support to cancellation and progress reporting, while Dispatcher (MSDN link) is a handy property from the UserControl class (the one used as a base class to Silverlight pages) that gives us access to the UI thread.

Let’s see a simple example on how to implement the proposed solution.

using System;
using System.ComponentModel;
using System.Threading;

public class Page : UserControl
{
    // Bogus is any given class with an asynchronous call
    private Bogus bogus;
    private BackgroundWorker bgWorker;

    public Page()
    {
        InitializeComponent();

        // Creates the BackgroundWorker and says it supports cancellation
        bgWorker = new BackgroundWorker();
        bgWorker.WorkerSupportsCancellation = true;

        // Registers the listener
        bgWorker.DoWork += new DoWorkEventHandler(bgWorker_DoWork);

        // Instantiate the class that runs the asynchronous call
        bogus = new Bogus();
    }

    #region Button handlers
    private void btnCallAsync_OnClicked(object sender, EventArgs e)
    {
        // Registers the listener for handling the result for the asynchronous call
        bogus.BogusCompleted += new BogusEventHandler(bogus_BogusCompleted);

        // The "please wait" message
        lblText.Text = "Please wait while operation is processed...";

        // Run the BackgroundWorker thread
        bgWorker.RunWorkerAsync();
    }

    // Handles cancelation of the asynchronous call
    private void btnCancel_OnClicked(object sender, EventArgs e)
    {
        // Let's unregister the listener so that the asynchronous call
        // result is not handled
        bogus.BogusCompleted -= new BogusEventHandler(bogus_BogusCompleted);

        // Removes the "please wait" message
        lblText.Text = string.Empty;

        // Cancels the BackgroundWorker thread
        bgWorker.CancelAsync();
    }
    #endregion Button handlers

    private void bgWorker_DoWork(object sender, DoWorkEventArgs e)
    {
        // Let's run it unless the BackgroundWorker is pending
        // cancelation
        if(!bgWorker.CancellationPending)
        {
            // This is not UI thread, since we are inside the
            // BackgroundWorker execution thread
            Thread.Sleep(new TimeSpan(0, 0, 3));

            // After sleeping for some time to allow users to read
            // the message, we start the asynchronous call
            bogus.RunBogusAsync();
        }
    }

    private void bogus_BogusCompleted(sender object, BogusEventArgs e)
    {
        // Any operations you want to execute in the UI thread
        // as a result of the asynchronous call
        Dispatcher.BeginInvoke(() => { UIOperations(); });

        // Unregister the listener since the call was already processed
        // and it is registered back on btnCallAsync_OnClicked()
        bogus.BogusCompleted -= new BogusEventHandler(bogus_BogusCompleted);
    }
}

So now let’s see in detail what the above code does.

The xaml file includes three controls: lblText (TextBlock control), btnCallAsync and btnCancel (Button controls).

As shown on btnCallAsync_OnClicked() (lines 27 to 37), lblText will display the wait message when btnCallAsync is clicked. Additionally, it will register the listener for BogusCompleted event and trigger the execution of the background worker.

bgWorker_DoWork() (lines 54 to 68) will then sleep the BackgroundWorker thread for a while and finally call the asynchronous method RunBogusAsync() which we were originally interested in.

On BogusCompleted, bogus_BogusCompleted() (lines 70 to 79) is finally run and Dispatcher.BeginInvoke() is called (using lambda expressions) to run something on the UI thread. We also unregister the listener for BogusCompleted events, since it is registered back every time btnCallAsync is clicked.

Sure we have a problem in this approach: we sleep the thread for some seconds before calling the asynchronous call, and that might cause a long wait in case Bogus.RunBogusAsync() takes too long to execute. For example, if the asynchronous call took five seconds to complete, we would keep the user waiting for eight seconds.

As an exercise, put the BackgroundWorker thread to sleep after the call to Bogus.RunBogusAsync(), and only if the asynchronous call didn’t take more than three seconds, so that the total wait would be at least three seconds, but no unnecessary extra time when.

Acho que desse jeito um número maior de pessoas poderá se beneficiar, via google e outros, dos assuntos tratados nos posts.

Yep, it’s in English from now on.