I’m now the sole developer working on arguably one of the largest projects for our company, and things are going well. However, I keep falling into traps and pitfalls created by one of the projects last programmers.

One of his “favourite” tricks seems to be creating a business layer method that populates an object based on data retrieved from a database. Nothing odd there.. but it’s when you have the need to re-use one of his functions that you end up falling right into his carefully seeded trap!

For example, we have an object called “CustomerSite”, which as the name suggests, has various properties that pertain to a customer’s site – 15 individual properties to be exact.
Whilst writing an additional management page for the project today, I had the need to get a “CustomerSite” object from the database, based on the site code.
A quick look through our data access methods reveals a pre-written method “GetCustomerSiteBySiteCode”. Excellent; No need to write a new stored proc and no need to write the retrieval C# code!

However, in hindsight I knew this particular programmer had written both the retrieval method and the stored proc, so I should have checked ahead of time, but alas I did not…

So I fire up my new shiny page and all goes well, right up to when my codebehind calls the “GetCustomerSiteBySiteCode” method. At which point, my page throws a wobbly with invalid use of null errors throwing hand over fist.

Initially, I start checking the database to make sure the data is actually fine for the customer site I selected. With that being fine, I check my code to make sure I’m not doing anything daft. Happy that I’ve not, it’s time to place a breakpoint and step on through…

It’s at the point I step into “GetCustomerSiteBySiteCode” that I realise I’ve been stung; Despite the “CustomerSite” object having 15 properties, only TWO of them are being set by this method – the rest are simply set to null.

After altering the method to actually populate all 15 properties, I checked the stored procedure, to find two select statements, the first with all fifteen fields commented out with the note “Probably want to include these fields later, but haven’t the need to use them yet.”

To quote Peter Griffin “This really grinds my gears”. It was the programmer who created the “CustomerSite” object to begin with, and it’s always had all 15 properties from the get go. It’s simply a case of laziness and lack of forethought; there’s every reason to believe that this method would be called elsewhere, especially as when he was working on the project, it was a multi-person project.

Grr.

On the face of it, it sounded like an easy answer. I knew you could disable both the minimize and maximize buttons very easily from within the Visual Studio GUI – so surely there’s an option for the third button; the close button?
Actually, no. Whilst you can remove all three buttons in one go (changing the setting “ControlBox” to false.) and as previously mentioned, you can disable the maximize and minimize buttons (“MaximizeBox” and “MinimizeBox” settings respectively), there is no setting to directly control the Close button.

A quick Google search produced a few varied approaches, but the one I suggested my colleague to implement is as follows:

1
2
3
4
5
6
7
8
9
10

private const int CP_NOCLOSE_BUTTON = 0x200;
protected override CreateParams CreateParams
{
    get
    {
        CreateParams mdiCp = base.CreateParams;
        mdiCp.ClassStyle = mdiCp.ClassStyle | CP_NOCLOSE_BUTTON;
        return mdiCp;
    }
}

This small bit of code simply needs to be placed within your form class; It overrides a property that is already called when a form is initialised, so doesn’t need to be explicitly called.

Some before and after shots:

My initial thoughts were to examine the executing processes and check for the existence of the application in the list:

1
2
3
4
5
6
7
8

    string procName = Process.GetCurrentProcess().ProcessName;           
    Process[] processes= Process.GetProcessesByName(procName);
 
    if (processes.Length == 1)
    {
        //run application
        ...
    }

Now, whilst this works, it is easily “beatable” by simply changing the executable’s name. Doing so will cause the method “GetProcessessByName()” to return only a single match, instead of the current application and any other duplicate instances.

After pondering on the subject for a while, I started to think how threading works, or more precisely, how threading deals with shared resources.

When a thread attempts to access a shared resource, an exclusive lock is applied to that resource until the thread completes it’s task. These locks are actually “Mutex” objects (read more here).

Using a Mutex, I was able to create the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13

    bool isFirstInstance;
    Mutex mx = new Mutex(true,"Global\\MyApplicationName",out isFirstInstance);
 
    if (isFirstInstance)
    {
        //run application
        ...
        mx.Close();
    }
    else
    {
        //application already running
    }

The “Global\\” prefix tells the Mutex to be available across all user instances on the machine, not just the current.

Also, whilst it’s not strictly required to close the Mutex before exiting, as it will be automatically closed when the application ends, I’ve added it in this example for completeness.

In my opinion, this method is more reliable, more robust, and slightly cooler

Now, whilst I agree that cross-thread operations should be handled correctly, and I’m actually glad Microsoft decided to tighten its belt over this when it came to creating the dotNet framework, it just seems very “bloaty” to have to write methods such as the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

delegate void SetFirstNameTextCallBack(string value);
private void SetFirstNameText(string value)
{
   if (txtFirstName.InvokeRequired)
   {
      SetFirstNameTextCallBack cb = new SetFirstNameTextCallBack(SetFirstNameText);
      cb.Invoke(value);
   }
   else
   {
      txtFirstName.Text = value;
   }
}

Ok, you can get a bit cleverer and write delegates and methods that expect a control, property name and property value to be provided, such as this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

delegate void SetControlPropertyCallBack(Control control, string property, object value);
private void SetControlProperty(Control control, string property, object value)
{
   if (control.InvokeRequired)
   {
      SetControlPropertyCallBack cb = new SetControlPropertyCallBack(SetControlProperty);
      cb.Invoke(control, property, value);
   }
   else
   {
      Type t = control.GetType();
      System.Reflection.PropertyInfo propInf = t.GetProperties().First(p => p.Name.ToUpper() == property.ToUpper());
      propInf.SetValue(control, value, null);
   }
}

But it still looks yuck to me.

Over the last few weeks, I’ve been increasingly using lambda and extension methods, and came up with a new way of handling invokes that I actually like!
It involves extending the “Invoke” method, as shown below:

1
2
3
4
5
6
7
8
9
10
11

public static TResult Invoke(this T controlToInvokeOn, Func codeToInvoke) where T : Control
{
   if (controlToInvokeOn.InvokeRequired)
   {
      return (TResult)controlToInvokeOn.Invoke(codeToInvoke);
   }
   else
   {
      return (TResult)codeToInvoke();
   }
}

With this implemented, any time you need to invoke anything, you can do so quickly and elegantly with a little lambda:

1

txtFirstName.Invoke(()=>Text = "test");