On my new project we are evaluating using Visual Studio 2010, but still building against .NET 3.5 ... for the time being.
We have been experiencing frequent lockups of the IDE and crashes.
After some investigation I came across a couple of possible reasons:
AnkhSVN version (via Resharper Blog) ... http://blogs.jetbrains.com/dotnet/tag/resharper-51/
Patch for VS2010 Cut and Paste ... http://blogs.msdn.com/b/visualstudio/archive/2010/06/25/patch-available-for-cut-or-copy-displaying-insufficient-memory-error-in-vs-2010.aspx
We are still seeing the odd crash/hang but it has improved the situation a lot.
Hope this is useful for someone.
I learnt about VS2010 crashes and a few possible solutions Friday, 2 July 2010
Posted by Mark Rainey at 08:32 0 comments
I learnt how to inject WPF DataTemplates into a window using MEF Wednesday, 10 February 2010
I am working on a WPF project where it needs to be able to support new item types dynamically. I am writing the core framework and other teams will produce functionality specific to certain object types.
This has all been working fine until I hit the scenario where I have a screen and a section of it needs to be built based on the object type.
In the non-extensible approach you would use a series of data templates which would then populate the section based on the item type.
However in my scenario these templates need to implemented by third parties. Wouldn’t it be nice to be able to inject these into the window at run-time.
We are using MEF for our extensibility and already have the means to inject custom controls into windows. However this problem seems more suited to using DataTemplates rather than having to know which control to inject.
The solution I have produced is as follows:
1. The user creates a data template in a resource dictionary and adds it to their assembly. Fairly standard stuff.
2. I have a static class (yes this could be injected as well) that locates a resource within an assembly.
public static class ResourceLocator
{
/// <summary>
/// Gets the first matching resource of the type.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="assemblyName">Name of the assembly.</param>
/// <param name="resourceFilename">The resource filename.</param>
/// <returns></returns>
public static T GetResource<T>(string assemblyName, string resourceFilename) where T : class
{
return GetResource<T>(assemblyName, resourceFilename, String.Empty);
}
/// <summary>
/// Gets the resource by name
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="assemblyName">Name of the assembly.</param>
/// <param name="resourceFilename">The resource filename.</param>
/// <param name="name">The name.</param>
/// <returns></returns>
public static T GetResource<T>(string assemblyName, string resourceFilename, string name) where T : class
{
if (string.IsNullOrEmpty(assemblyName) || string.IsNullOrEmpty(resourceFilename))
return default(T);
string uriPath = string.Format("/{0};component/{1}", assemblyName, resourceFilename);
Uri uri = new Uri(uriPath, UriKind.Relative);
ResourceDictionary resource = Application.LoadComponent(uri) as ResourceDictionary;
if (resource == null)
return default(T);
if (!string.IsNullOrEmpty(name))
{
if (resource.Contains(name))
return resource[name] as T;
return default(T);
}
return resource.Values.OfType<T>().FirstOrDefault();
}
}
3. In the third party assembly it calls the ResourceLocator somewhere to locate the template:
m_template = ResourceLocator.GetResource<DataTemplate>("TheAssemblyName","Resources/TheResources.xaml");Where the first parameter is the name of the assembly and the second in the name of the file with the resource (this could be in the static constructor).
4. This is where MEF kicks in. I now have a property that exposes this DataTemplate using a known contract name.
[Export(MyTemplateContract)]
public DataTemplate MyTemplate
{
get { return m_template; }
}
5. In MEF I can now import all the instances of the MyTemplateContract and inject them into my window resources.
private void LoadTemplates()
{
IEnumerable<DataTemplate> templates = Composer.GetExportedObjects<DataTemplate>(MyTemplateContract);
foreach (DataTemplate template in templates)
Resources.Add(template.DataTemplateKey, template);
}
And that’s it. Now the other teams can create a new data template, use the resource locator to find it and export it as a property. My application will then pick these up at run-time and inject them into the window.
Posted by Mark Rainey at 15:53 1 comments
I learnt how a restaurant influences choices Wednesday, 23 December 2009
This article has a very interesting study on how restaurants can influence choices of dishes. I will never look at a menu the same way again.
Restaurants Use Menu Psychology to Entice Diners - NYTimes.com
I wonder what other areas have the same approaches. Supermarkets is an obvious example.
And how difficult would it be to come up with a set of "rules" for a completely new domain.
Update: And along the same lines ... The hidden psychology of menu design
Posted by Mark Rainey at 14:16 0 comments
Labels: Misc
I learnt about formatting multiple strings in a binding
Such an obvious solution, but in the past I have tended to write converters to format multiple values:
<MultiBinding StringFormat=”Date: {0:MM/dd/yyyy}, Percent: {1:P}”>
<Binding Path=”BeginDate” />
<Binding Path=”Percent” />
</MultiBinding>
From http://goldmanalpha.wordpress.com/2009/12/23/lab-this-month/
Posted by Mark Rainey at 14:13 0 comments
Labels: WPF
I learnt about checking a .NET application is running as 32 bit Tuesday, 8 December 2009
We had a scenario where an application had to run as 32 bit on a 64 bit server, due to an external library.
I’ve used the corflags command line tool in the past but in this scenario we are using the Target Platform flag in the build. As I don’t have access to the server it is deployed on I needed to check that the build was being built with the correct flag.
I came across this page:
http://bytes.com/topic/net/answers/617520-how-determine-assemblys-target-platform
Using the information on this page I was able to check, using ildasm, that the build was being done correctly.
Posted by Mark Rainey at 15:49 0 comments
Labels: C#
I learnt about a nice side effect of view models, tab controls and data context Tuesday, 24 November 2009
I am currently working on a new piece of functionality for an application. Up until now it had assumed that there would only be one instance of a grid in a panel however, as often happens, the requirement has arisen to support multiple grids each hosted in a separate tab – built dynamically at run-time, using MEF.
This has meant refactoring the current solution and splitting it into two – a user control for the grid part and a user control to host the tabs.
In the host control there is a toolbar that will be the same for all tabs but needs to be linked to the current tab. This existed in the current solution and up until now the toolbar data-binds to commands in the view model for the grid (we are using MVVM).
My initial thought was to pull the commands out into the main host for the tabs.
However one of the nice side effects of the approach is that if I change the DataContext of the toolbar to the DataContext of the current grid as the toolbar selection changes it will all work for free and there is no need for the commands to be moved up or to worry about which is the selected tab etc. Nice.
Posted by Mark Rainey at 09:51 0 comments
Labels: WPF
I learnt about "talking to the rubber duck" Sunday, 15 November 2009
In my first professional programming role my boss at the time mentioned about talking to a plastic duck. After the initial concerns about his sanity, he explained that he had a plastic duck on top of his monitor so that when he hit problems he would talk to the duck and in a lot of cases the process of talking to the duck would help him to solve the problem.
Now I have never resorted to actually acquiring a duck for this purpose however it is amazing how many times just talking to someone and explaining the problem brings the solution to mind, and in a lot of cases without the other person even saying a word.
So, when I came across the following article (A reminder to talk to the rubber duck) it made me smile.
It did have one tip in there which I may give a try for when it is inconvenient to talk to others or no-one is around:
"One way to do it that works particularly well is to write an e-mail message explaining your problem. Pretend you’re going to send it to the smartest (and busiest) person in the world. Describe the problem in detail, the solutions you tried so far and why they didn’t work. List your assumptions and make sure you include all relevant information. Be both thorough and objective."
Posted by Mark Rainey at 21:39 0 comments
Labels: C#