Archives

Anticipation

  • No dates present

Gaming Update: Dec 2011

Well, it’s been a while since I last posted about games, and in that time I’ve played quite a lot of them. I’m not going to mention all of them (I’m sure I’ve forgotten quite a few), but I will say a few words about some of the more notable ones. In no particular order:
Continue reading Gaming Update: Dec 2011

AppDomains and unmanaged callbacks, redux

Quite a while back, I posted an article about getting native callbacks to work across AppDomains. Since then, I’ve gotten quite a few comments with varying levels of confusion, and seen a few implementations that appear to have missed something along the way. So I thought it’d be a good idea to post a clarification.

Fundamentally, there are just a few things that you need to remember:

  • You cannot access managed objects (including GCHandles and gcroots) outside of the AppDomain in which they were created.
  • Each thread which has executed managed code has a “history” linking it to a particular AppDomain. If a thread has never executed managed code before, though, then the first time it tries it will be assumed to be in the first AppDomain.
  • Delegates contain information about which AppDomain they should be executed in, so they can “cross the line” when an otherwise pure native thread has no idea which AppDomain it should be using.
  • Managed delegates can be turned into native function pointers via the Marshal::GetFunctionPointerForDelegate method.
  • If you create a function pointer from a delegate, you must keep the delegate alive (by keeping a reference to it) for as long as the native pointer exists.
  • Native functions can only have native types as parameters (but they don’t have to just be primitive types). (Actually, there are some limited exceptions to this, which I cover below.)

So, here’s a few example scenarios, to get your head around the ideas. Note that none of these care whether you’re crossing AppDomain boundaries or not (they’re cross-AppDomain-safe, but can be used within the same AppDomain too), so they can also serve as good examples for regular interop scenarios as well.
Continue reading AppDomains and unmanaged callbacks, redux

111111111111

I’m retroactively declaring this as a significant post date. :) (Hey, it’s been two years since I last did this.)

Historical Significance.

Conversion Filter

Finally, the last post in my series about conversion and the LookupConverter.

This is just a quick addition to extend the capabilities of the LookupConverter, specifically to allow it to run a bit of code to determine which resulting value to use. I’ve actually never used this in a real-world scenario myself (I’ve always found alternatives), since the goal of the LookupConverter in the first place was to avoid having to write code, and because for obvious reasons this will only work in a one-way scenario. But some people might find it useful.
Continue reading Conversion Filter

A Tableau of Conversion

Some people might be wondering why I said that the last two Programming posts were part of a series — after all, the first one was a utility class to help out with type conversion, while the second one focused on using enumerations in the UI. How is that a series? Well, it’s this post which should help to tie everything together.

I mentioned in the last post that a significant drawback of the technique presented there was that it presents the internal names from the code directly to the user. Sometimes that’s ok, if you’re writing something for internal use, or if the names are short enough (a single word) and intended for an audience that speaks a single language. But that still eliminates a lot of potential usefulness.

As a reminder, the (somewhat contrived) example from the previous post went something like this:

<window .Resources>
    <objectdataprovider x:Key="ReportTypes" ObjectType="{x:Type System:Enum}" MethodName="GetValues">
        </objectdataprovider><objectdataprovider .MethodParameters>
            <x:type TypeName="app:ReportType"></x:type>
        </objectdataprovider>
 
    <app:reporttypesconverter x:Key="ReportTypesConverter"></app:reporttypesconverter>
    <datatemplate DataType="{x:Type app:ReportTypes}">
        <textblock Text="{Binding Converter={StaticResource ReportTypesConverter}}"></textblock>
    </datatemplate>
</window>
...
    <combobox ItemsSource="{Binding Source={StaticResource ReportTypes}}" SelectedItem="{Binding ReportType, Mode=TwoWay}"></combobox>

But the ReportTypesConverter isn’t very satisfactory there — it requires specific code to be written for each enum type for each set of different text you want to provide (which can potentially mean that in some cases you’ll need more than one converter for a single enum type, if it’s used in different contexts where you want to use different text). And something just feels wrong about putting something so fundamentally UI-related as what text to display in the combo box in the code of a converter class rather than in the view itself.

So I went looking for a better way. Continue reading A Tableau of Conversion

Fable the Third

Fable 3 (Amazon, Mighty Ape, Steam) was released a month or so ago (for PC, anyway), and I finished my first playthrough not that long ago.

I’d seen fairly mixed reviews of the Xbox version beforehand, but I was going in with fairly light expectations — I’d played Fable: TLC (on PC too, of course) previously and found it to be a fairly light-hearted and silly RPG, but still pretty fun. I haven’t played Fable 2 (since it never made it to PC), but I was expecting something similar from Fable 3.
Continue reading Fable the Third

Combos of Enums

It’s probably about time that I continued on from my previous post. This one is just going to be a short one, but it’s a nice setup for the following post in the series.

When you have a property which can only have one of a limited number of values, there are a few different ways to represent it — both in the UI and in the code. In the UI, the choice is usually between a combo box and a list box, with which one you choose partly driven by personal taste and partly based on whether you think it might be possible to support multiple selections in the future — in general, a combo box is ideal for cases which only support a single selection, and a list box for cases with multiple selections. (These aren’t hard limitations, of course — you can have a single-select list box or a combo-box which does multi-select with a lingering drop-down or just via checkboxes in its drop-down, and sometimes you’ll want to do this for aesthetic or sizing reasons — but those are the conventions that people have come to expect.)

In the code, you can create a collection and fill it with all possible values as discrete objects; this certainly makes it nice and easy to bind to the UI, and is really the only option if all the possible values aren’t known at compile time (eg. you have to load them from a database, or you’re letting the user select between items they’ve already created in some other part of your software). If you know all the possible values at compile time, though, and there isn’t any “extra” info you need to store about a single item, then an enumeration is a good fit to represent the value in your data model.

Once you have an enumeration in the data model, though, how do you get its values into the combo box? One way of course is to “translate” it in your view-model layer, by converting it from the enum value to one of a collection of UI placeholder objects (as described above), and then back again. That seems like quite a bit of overhead, though.

Another way to do it is to get the .NET framework itself to help you out. There’s a static method you can call which returns a collection of all the possible values of an enum type (this is Enum.GetValues). You could expose this as a property in your view-model and bind to it, but you can instead get the XAML to do all the work for you:

<Window.Resources>
    <ObjectDataProvider x:Key="ReportTypes" ObjectType="{x:Type System:Enum}" MethodName="GetValues">
        <ObjectDataProvider.MethodParameters>
            <x:Type TypeName="app:ReportType" />
        </ObjectDataProvider.MethodParameters>
    </ObjectDataProvider>
</Window.Resources>
    ...
    <ComboBox ItemsSource="{Binding Source={StaticResource ReportTypes}}" SelectedItem="{Binding ReportType, Mode=TwoWay}" />

(This will obtain the values in the same order in which they’re defined in the code, which is usually what you want — but you can interpose something which sorts the list as well if you like.)

If you try this for yourself, though, you’ll find that it has a bit of a hole — the enum values are presented to the user using the same name as it appears in code. Now, if your enum values are simple enough (a single word, for example, so you don’t run into BumpyCasingIssues), or if this is for a prototype or otherwise cheap and hacky program, then this might be ok, but for most real-world usage it leaves a bit to be desired.

<Window.Resources>
    <app:ReportTypesConverter x:Key="ReportTypesConverter" />
    <DataTemplate DataType="{x:Type app:ReportTypes}">
        <TextBlock Text="{Binding Converter={StaticResource ReportTypesConverter}}" />
    </DataTemplate>
</Window.Resources>

The standard way of changing the appearance of an item in WPF is to template it, and this is no exception. By adding the code above, the enum values will automatically be displayed in the UI using the text returned by the ReportTypesConverter, which is an IValueConverter you’ll have to write yourself that converts from an enum value to the text you want to display for it in the UI. (Note that you don’t have to write a conversion back the other way.) You can use similar techniques if you wanted to do something else with your enums — for example, displaying an image in addition to or instead of the text.

[Conversion(typeof(ReportTypes), typeof(string))]
public class ReportTypesConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        switch ((ReportTypes)value)
        {
            case ReportTypes.Basic: return "Basic Report";
            case ReportTypes.Extended: return "Enhanced Report (includes section B)";
            ...
        }
        return "Unknown (" + value + ")";
    }
 
    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotSupportedException();
    }
}

You can get quite fancy in this converter (eg. handling translation) — and there’s even a technique you can use to let you use a Description attribute on the enum values themselves to define the text you want to show in the UI (and a further technique to extend that to be translatable); which at least means you’d only need to write one converter which would work for all enum types. But I’m not going to go into that at the moment. (I can post it if there’s sufficient interest, but I don’t really like that solution as it mixes too much UI-view stuff into the data-model.)

There’s yet another way to do it, though, which I think is a bit more elegant — but that will have to wait until the next post in the series.

Clever Conversion

I’ve been planning to post this (and a few other things) for a while now, but never quite seemed to get around to it. Well, brace yourselves, because here it finally is! (And it might even turn into an actual series!)

This first part is pretty straightforward; it’s a helper class designed to make a best-effort attempt to convert any object into a specific type, by making use of any defined converters. It’s the sort of thing you’d think Convert.ChangeType would do (but doesn’t, because that only works for the native value types), and what the WPF XAML parser actually does do (although unfortunately it doesn’t seem to expose its underlying mechanism for external use; at least not that I could find).

But let’s get straight into the code:

    public static class ConversionUtilities
    {
        /// <summary>Convert the given value to the specified type (if possible).  Requires a direct <see cref="TypeConverter"/> conversion to work.</summary>
        /// <param name="currentValue">The value to be converted.</param>
        /// <param name="expectedType">The type to convert the value to.</param>
        /// <returns>The converted value; or the original value if the conversion is not necessary or not possible.</returns>
        /// <exception cref="Exception">Any exceptions thrown by the conversion operation will be propagated outwards.</exception>
        public static object Convert(object currentValue, Type expectedType)
        {
            var convertedValue = currentValue;
            if (convertedValue == null) { return convertedValue; }
            if (expectedType.IsAssignableFrom(convertedValue.GetType())) { return convertedValue; }
 
            var converter = TypeDescriptor.GetConverter(expectedType);
            if (converter != null && converter.CanConvertFrom(convertedValue.GetType()))
            {
                convertedValue = converter.ConvertFrom(convertedValue);
            }
            else
            {
                converter = TypeDescriptor.GetConverter(convertedValue.GetType());
                if (converter != null && converter.CanConvertTo(expectedType))
                {
                    convertedValue = converter.ConvertTo(convertedValue, expectedType);
                }
            }
            return convertedValue;
        }
 
        /// <summary>Convert the given value to the specified type (if possible).  Requires a direct <see cref="TypeConverter"/> conversion to work.</summary>
        /// <param name="currentValue">The value to be converted.</param>
        /// <typeparam name="T">The type to convert the value to.</typeparam>
        /// <returns>The converted value.</returns>
        /// <exception cref="InvalidCastException">Thrown if the specified conversion is not defined.</exception>
        /// <exception cref="Exception">Any exceptions thrown by the conversion operation will be propagated outwards.</exception>
        public static T Convert<T>(object currentValue)
        {
            if (currentValue == null) { return default(T); }
            return (T)Convert(currentValue, typeof(T));
        }
 
        /// <summary>Compares two objects for equality, applying conversions (if possible) if their types differ.</summary>
        /// <param name="a">The first object to compare.</param>
        /// <param name="b">The second object to compare.</param>
        /// <returns>True if the objects are convertible to an equal value.</returns>
        public static bool EqualsWithConversion(object a, object b)
        {
            if (a == null && b == null) { return true; }
            if (a == null || b == null) { return false; }
 
            if (Equals(a, b)) { return true; }
            if (Equals(Convert(a, b.GetType()), b)) { return true; }
            if (Equals(a, Convert(b, a.GetType()))) { return true; }
            return false;
        }
    }

Note that if the conversion is not possible, then the first method will return the original object, which will result in the second method throwing an InvalidCastException.

These methods only support a single conversion step — if Foo and Bar are both convertible to String (as all objects are, ultimately), then it will let you convert either a Foo object or a Bar object to a string (or vice versa, if the reverse conversion has been defined), but it will not let you convert a Foo object into a Bar object directly — although you can request the intermediate conversion yourself if that’s what you really want:

ConversionUtilities.Convert<Bar>(ConversionUtilities.Convert<string>(foo))

I chose this limitation both to help avoid potential loops if complex conversion paths are available, and because letting it chain through more than one conversion step at a time could easily lead to a loss of information or other surprising behaviour — especially since every object is convertible to a string (though not necessarily back from a string), but those conversions aren’t necessarily all that helpful.

We’ll cover a particularly interesting use for this class in a later post.

Scott Pilgrim

I’ve been meaning to post this for a couple of weeks, but you know me. I figured I had better do it before it’s completely gone from the theatres, at least.

If you’re into computer games at all (with particular emphasis on the old 8-bit Nintendo games, but any gaming interest is probably good enough), then Scott Pilgrim vs. the World is definitely a good movie to go and see.

On the surface (and for the first 20 minutes or so), it’s basically just your boring average run of the mill cheesy teen romance stuff, although occasional glimmers of interest peek through sometimes (and it’s really hard to like the main character at this point; not sure if that’s intentional or not). Once you get past that part, though (basically shortly after Ramona first appears), the action heats up and things just get insanely awesome.

I guess it has a bit of a niche audience (which is probably why according to most reports it’s been fairly mediocre at the box office), but for those people squarely in its niche (like me), it’s one to be remembered.

Here’s the official trailer:

YouTube - Link to Scott Pilgrim Vs. The World Theatrical Trailer

And, just for added awesome points, here’s a fan trailer combining video from the Matrix series with audio from the Scott Pilgrim trailer (which works out surprisingly well):

YouTube - Link to Scott Pilgrim VS THE MATRIX

Templates Galore

(Well, look at that. I did manage to write another Programming post after all.)

One of the really great things about WPF is its composable UI structure and dynamic layouts — the ability to replace one set of controls with another on the fly as things happen (eg. when something is selected by the user) and have everything adjust accordingly. The data binding engine is one of the most important elements in this, but closely linked to it is the templating engine.

In this post I’ll cover a little bit of background behind DataTemplates, but the primary focus is going to be on the DataTemplateSelector — what it is, why you might want to use it, a way to make it easier to use, and finally a better alternative to using them at all.
Continue reading Templates Galore