Ok, so the previous post I discussed a service locator implementation based on the Martin Fowler registry example.  After some thought and discussion with a couple of friends I decided the previous implementation was a bit too strict for it's own good.  So I have come with a way that still gives you generic goodness, it does however suffer from boxing/unboxing which may give you a slight performance penalty vs. my previous implementation but the penalty should be minimal if noticeable at all.

The new service locator implementation:

  public interface IService { }
    public class ServiceLocator
    {
        private static ServiceLocator _instance;
        private ServiceLocator() { }

        private static Dictionary<string, object> _map = new Dictionary<string, object>();

        public static ServiceLocator Instance
        {
            get
            {
                if (_instance == null)
                {
                    _instance = new ServiceLocator();
                }
                return _instance;
            }
        }

        public void Load<T>(T service) where T: IService
        {
            Load(typeof(T).FullName, service);
        }

        public void Load<T>(string key, T service) where T : IService
        {
            _map.Add(key, service);
        }

        public T Get<T>() where T : IService
        {
            return Get<T>(typeof(T).FullName);
        }

        public T Get<T>(string key) where T : IService
        {
            return (T)_map[key];
        }
    }

To use this the syntax is slightly different than before, this time everything is method based.  I still constrain the methods to the IService type, for some reason  it just gives me a warm and fuzzy feeling when I use the constraint. It is obviously up to you whether or not you want to use it, you could delete the marker interface and the constraints completely and it will work just fine.

To Get: MyService wmiService = ServiceLocator.Instance.Get<MyService>();
To Load: ServiceLocator.Instance.Load<WMIService>(new WMIService());

So both versions work, both versions are acceptable solutions but this one is more flexible than the last version.  In particular this version allows a greater degree of flexibility around unit testing and mocking frameworks.

So I came across the need for a service locator but I didn't want to use a framework since my needs were relatively lightweight, and mostly based around testing.  So looking at Martin Fowlers examples of Service Locators I adopted them and came up with a .NET way of doing it using Generics.  It is of course flexible, the method I am offering obviously has a couple of constraints that I have put in place on purpose for my scenario.  One of them being I wanted only one instance of a service set in the service locator at any given time, so you could very easily adapt it to suit your own needs. 

Also the interface specified is a marker interface used to specify a constraint on the generic, the idea was that all services would be marked with this interface.

 public interface IService { }

    public class ServiceLocator<T> where T : IService
    {
        private static Dictionary<string, T> _map = new Dictionary<string, T>();
        private ServiceLocator() { }

        public static void Load(T service)
        {
           _map.Add(typeof(T).FullName, service);
        }

        public static T Get()
        {
            return _map[typeof(T).FullName];
        }
    }

An example of a service would be like follows:

public class MyService : IService
{
    //Whatever Methods
}

Then on application startup you would obviously load all of your services into the service locator:

MyService myService = new MyService(...);
//...do whatever you need to setup the service

ServiceLocator<MyService>.Load(myService);

So later on anywhere in your code you simply do a

MyService myService = ServiceLocator<MyService>.Get();

It's pretty simple but just in case...As you can see I chose to use the FullName of the type as the key in map, you could always choose to do it the way Martin Fowler did where you simply expose the instance of each service type directly but for me I kind of liked this method.

Been working on a new application called VistaTune, it is open on CodePlex so you should go check it out but basically its an application that will enable you to tune Vista as well as setup profiles to use for certain "modes" such as gaming, developing, etc.  In any case during my development I noticed that the ServiceController class of .NET is lacking in that it does not allow you to change the Startup Mode of a service.  Personally I find this kind of odd since it lets you do everything else, so I went ahead and wrote an Extension Method for this class.

The below code is the cleanest and quickest implementation I could come up with, note that editing the registry to change the behavior of a service is considered evil and is very problematic so I would not recommend that route.

        public static void ChangeStartMode(this ServiceController sc, ServiceStartMode mode)
        {
            ManagementPath managementPath = new ManagementPath()
            {
                Server = System.Environment.MachineName,
                NamespacePath = ManagementPath.DefaultPath.NamespacePath,
                RelativePath = String.Format("Win32_Service.Name='{0}'", sc.ServiceName)
            };

            //Method: ChangeStartMode, Parameters: Mode (string), Return Value: int (0 success)
            new ManagementObject(managementPath).InvokeMethod("ChangeStartMode", new object[] { mode.ToString() });
        }

I hope this helps anyone that is having this problem, I did not find very good solutions to this problem when I was searching for it.  Also most of the code samples I found were very dirty, created lots of objects that were not necessary, etc.

If you bind a property to a UI element and then changed the value of that property on the back end entity the UI will not reflect that change unless you update the UI manually right?  Well no, not entirely true, and in my case I am going to speak WPF because I do not know if this is available in WinForms since I never used it in WinForms.

Let's say for example you have a ListView control that is bound to "Balance" for all 45 items, let say you have a background thread that is processing and is going through the records and updating this value.  How nice would it be for the UI to automatically update when this happen?  Well it's easily doable since binding automatically supports this functionality.

All you have to do is implement the INotifyPropertyChanged interface on your entity, after which you will get a new event.  Then in the method or property setter you fire this event, the UI will be watching for it and it will automatically fetch the new value for the value you specified.  This should also be faster since you don't need to update the entire binding context of the control.

Simply call PropertyChanged(this, new PropertyChangedEventArgs("Balance")) and only the specified property will update.

Was messing with the ListView control in WPF as usual and could not for the life of me figure out how to get the Image source attribute (Image is a separate control type) to show the image of a bitmap that I pulled from an icon from the system.  Basically what I was doing was I was using SHGetFileInfo to retrieve the icon of a particular file, I have two columns in my ListView.  The first column holds a <Image> element the second column holds a <TextBlock> element which displays the path.  I wanted the first column to display the system icon of the second column, so I retrieved this value through the windows API SHGetFileInfo (unmanaged) and got back an Icon which I then convert to a Bitmap.  I wrote a helper utility that does all of this, it also caches the images for common file extensions to prevent excessive system fetching. 

But setting the source in XAML to the property of type Bitmap does nothing, it turns out you have to set the source to the path of the image.  Well my question was, how do you specify the path of an image that you have in memory?  Also then how do you specify the path to XAML?  Well it turns out you can write something called a Converter that will convert the value of anything you want before the binding actually takes place.  Using the following XAML syntax to setup the binding, there are two steps, first you setup the local resource, second you specify the converter to use.

Resource:

   1:  <Window.Resources>

   2:      <custom:ImageConverter x:Key="imageConverter" />

   3:  </Window.Resources>

Binding Syntax:

<Image Source="{Binding Path=Image, Converter={StaticResource imageConverter}}" ... >

Next you must write the converter, since the convert I am using is read only the ConvertBack method does nothing.  There does not appear to be a read-only version of this interface so this is the best I could think of, in any case it works.  There is another interface called IMultiValueConverter, from what I gather it converts an array of objects handed to it.

The convert I wrote that takes a Bitmap and returns the source path:

   1:  [ValueConversion(typeof(Bitmap), typeof(string))]

   2:      public class ImageConverter : IValueConverter

   3:      {

   4:          public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

   5:          {

   6:              return Imaging.CreateBitmapSourceFromHBitmap(((Bitmap)value).GetHbitmap(), IntPtr.Zero, Int32Rect.Empty,

   7:                  BitmapSizeOptions.FromEmptyOptions());

   8:          }

   9:   

  10:          public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)

  11:          {

  12:              return null;

  13:          }

It returns a BitmapSource which it turns out is one of the types that you can bind to with the Image Source attribute in XAML, so this works.  So first off you do not want to use this for Resource files, you should use the built in WPF support such as setting the path to its package location:

"pack://application:,,/Resources/file.ico"

Which will work as long as you don't set the location of the resource to "Embedded Resource" since that is not supported.  If you need to store vector based graphics you can use the Resource Management support of WPF but if you can't for valid reasons than the above option seems to be your only one.

In a previous post I mentioned I couldn't figure out how to get a column to stretch the width of the control when it was expanded.  Well I stumbled onto a binding feature that is very very cool, its called RelativeSource and it lets you bind to properties on the control itself using the Self attribute, or the one I care about is child controls.

So in all its glory, the code that I use to set to an arbitrary number, is now set to a number that auto increments when the controls width is changed which you can verify by placing it in a text block.

   1:  Width="{Binding RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}, AncestorLevel=1}, Path=ActualWidth}"

So yes it is verbose, and yes at first glance its confusing but it makes sense when you understand what its doing.  It's just going one level down to its container, and then I am getting the ActualWidth of that container.  Why not width?  Well I don't set the width on that control so the width will be null actually, in WPF width does not give you the Width of the control.  Instead it gives you the width that you have set it to if ever, and ActualWidth gives you the current active width of the control.

Today has been a HUGE WPF day for me, I have spent the entire day working with it and its exciting.  I hope to share all my findings with everyone that needs it.  It is very difficult to find information on how to do a lot of the stuff I am posting about, most of it has taken me hours upon hours of trial and error to get it working.

In WPF the beloved and well known InvokeRequired method has disappeared from the framework.  Replacing it is the Dispatcher, and it's methods CheckAccess and VerifyAccess pretty much are the replacement for InvokeRequired.

So if you have done any new WPF work you will quickly think, what the hell am I talking about.  Because if you type Dispatcher and wait for intellisense you don't see these methods, well that's because they are explicitly hidden from intellisense.  One can assume they did this intentionally to prevent developers from overusing these methods, since every WPF object will periodically call these methods on their own it's not necessary for you to check manually.  Unless you are developing your own WPF object, at least that's my best guess.

They have actually marked the Dispatcher.CheckAccess and Dispatcher.VerifyAccess with the [EditorBrowsable(EditorBrowsableState.Never)] (thanks Karsten Januszewski)attribute so you can see that they are intentionally hiding this from view.  I hope more light is shed on this topic as it's quit confusing.  Also there is a hack circulating for a way to check if the executing thread needs to be marshalled or not by doing a comparison against the UI thread.  To me that code really makes me feel dirty just by looking at it.

So how do you use the Dispatcher?  Well there are numerous different ways, I prefer to use an anonymous delegate:

   1:   Dispatcher.BeginInvoke(DispatcherPriority.Normal, (ThreadStart)delegate

   2:  {

   3:    //Update UI 

   4:  });

You don't have to use the ThreadStart delegate, the reason I use it is simply because it takes no parameters.  You can also obviously point it at a method, or itself which if you do that you will need to use CheckAccess in that instance.  There is a very valid performance reasons controls don't check to see if they are on the correct thread every single time.  If you do it the second way you incur that overhead, so out of curiosity I ran a benchmark comparing the two styles.

In the first benchmark I used the method above, and got the following results (in milliseconds):

Algorithm used for benchmark (simulates a real world data event, think of the DataGrid):

   1:  ArrayList al = new ArrayList();

   2:  for (int i = 0; i < 100000; i++)

   3:  {

   4:    al.Add("Test");

   5:    if (NewItem != null)

   6:      NewItem(this, EventArgs.Empty);

   7:  }

Is this a 100% solid benchmark? Probably not, in fact someone else might be able to get differing results but it does show a difference which is really quit obvious.  You are calling an additional method so you would expect it to take slightly longer but it also illustrates why they don't call this on the WPF object for every single method call natively.

So far my experience with WPF has been well met, it is an extremely flexible system with a nearly limitless possibilities with customizing controls.  However, with flexibility often comes complexity.  So I have been messing with the ListView control and was trying to figure out how to hide the column headers, is it possible?  It didn't seem like the control even supported it...But then I remembered reading about Styles and how you can set nearly any property with a style, on any control whether its nested deep in the controls hierarchy or not.

So that's exactly what I did, and you can see my XAML for that below:

   1:  <GridView>

   2:    <GridView.ColumnHeaderContainerStyle>

   3:     <Style TargetType="GridViewColumnHeader">

   4:       <Setter Property="Visibility" Value="Hidden" />

   5:       <Setter Property="Height" Value="0" />

   6:     </Style>

   7:  </GridView.ColumnHeaderContainerStyle>

If there is an easier way to do that then I am all ears, please share the knowledge!

The next step in my customizing quest was I wanted two columns, the first one to show an icon, the second one to show text.  However, the ListView control was inside of a grid column with a grid splitter so this column could get bigger and the control along with it.  Which was desired, if you make the control bigger I wanted the text that was Ellipsed due to not enough space to show. 

This presented a problem, first how do you get the second column to take up the remaining room of the control?  Secondly, how do you get the text to ellipse when the control is cutting the text off?

The first one was not so easy to solve, and I actually never came up with a solid solution, more of a hack really and it only works since in my instance I don't need to have horizontal scrolling ability inside my ListView control. So the solution was to hide the horizontal scrollbar and set the column width to a very high number, which works but it's really a dirty solution.  Until someone can offer me a better solution this is the only one I could come up with.

Note: I solved this problem without the hack in a later post, you can view it here.

Ellipse Text XAML:

   1:  <GridViewColumn.CellTemplate>

   2:   <DataTemplate>

   3:    <Label HorizontalAlignment="Stretch">

   4:    <TextBlock Text="{Binding Path=Name}" Width="Auto" HorizontalAlignment="Stretch" TextTrimming="CharacterEllipsis" />

   5:     <Label.ToolTip>

   6:      <ToolTip>

   7:       <TextBlock Text="{Binding Path=Name}" />

   8:      </ToolTip>

   9:     </Label.ToolTip>

  10:    </Label>

  11:   </DataTemplate>

  12:  </GridViewColumn.CellTemplate>

Hide Horizontal Scrollbar XAML:

<ListView ItemsSource="{Binding}" ScrollViewer.HorizontalScrollBarVisibility="Disabled">

Last but least, normally each ListViewItem is only large enough to fit the contents.  In order to avoid this we set the ListView.ItemContainerStyle as seen below:

   1:  <ListView.ItemContainerStyle>

   2:   <Style TargetType="{x:Type ListViewItem}"><Setter Property="HorizontalContentAlignment" Value="Stretch" />

   3:   </Style>

   4:  </ListView.ItemContainerStyle>

So that's basically it for now, if you have any cool stuff you have find be sure to send them my way.  I am gathering that WPF is going to be a huge learning curve for everyone, going to take quit a while to get elite at this stuff.  Designers will be able to have a field day, but more often than not us poor developers are left doing both design and development.

using (Stream stream = fileDialog.OpenFile())
{
    TextRange tr = new TextRange(rtMain.Document.ContentStart, rtMain.Document.ContentEnd);
    tr.Load(stream, DataFormats.Text);
}

Now my first impressions were what the hell?  How does it work?  So on further investigation it's quit unique, the ContentStart, and ContendEnd properties are actually something called TextPointer and are indeed references and not integer values as one would expect from previous versions.  While this is not apparent it is much more elegant and gives you much more flexability at adding text in any spot you wish without changing the caret position, etc.