Posts in category .net - page 19

DiffMerge is free, try it with AnkhSVN

SourceGear, known for their Vault source control software, are giving away their three-way diff & merge tool DiffMerge for Windows, Mac and Unix.

DiffMerge has a clear interface and supports for file-type specific rule-sets that allow you to decide how to deal with white-space, line-endings, encoding etc.

I’ll be using it instead of my trusty KDiff for a couple of weeks to see how things go.

To use DiffMerge in AnkhSVN head into the Tools > AnkhSVN > Edit the AnkhSVN Configuration menu option and then paste each of the following command-lines into the associated configuration option.

DiffExePath

C:\\Program Files\\SourceGear\\DiffMerge\\DiffMerge.exe "%base" "%mine" /t1="Base version" /t2="My version"

MergeExePath

C:\\Program Files\\SourceGear\\DiffMerge\\DiffMerge.exe "%base" "%theirs" "%mine" /r="%merged" /t1="Base version" /t2="Their version" /t3="My version"

Alternatively you might want to check out Trevor Green’s instructions on using DiffMerge with TortoiseSVN if you are not yet sold on AnkhSVN and it’s Visual Studio integration.

[)amien

AnkhSVN and Visual Studio 2007/2008/Orcas

A newer registry file is available to provide AnkhSVN with Visual Studio 2008 and Vista support in one.

If you are using Visual Studio 2007/2008/Orcas/9.0 you will have found that AnkhSVN 1.01 doesn’t appear in the IDE.

Like many Visual Studio add-ins AnkhSVN should work just fine but won’t appear because the installer does not write an entry for it in the 9.0 section of the registry.

In this case the specific branches are:

  • 32-bit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AddIns\Ankh
  • 64-bit HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\8.0\AddIns\Ankh

All we need to do is export that section out, change the 8.0 to 9.0 and then run it back into the registry.

This technique should work for any other add-in’s you have that are only appearing in 2005.

If you installed AnkhSVN into the default folder try these registry files I have prepared for 32-bit or 64-bit machines.

[)amien

LINQ to SQL NullReferenceException on SubmitChanges

I’ve been busy working on some LINQ to SQL (formerly DLINQ) apps that have been going well bar a NullReferenceException thrown at me from deep in the bowels of LINQ and it’s change tracker. A cursory glance in debug showed none of the properties that represent columns were null…

The null was actually a collection property that represented a one-to-many relationship that was automatically created using the foreign key constraints in the database. Normally this is set to an empty EntitySet however I was failing to call the default constructor from my new useful constructor.

The moral of the story is always call the default constructor with this(), especially when extending generated code. So much for persistence ignorance.

public partial class Invoice {
  public Invoice(int number) : this() {
    this.number = number;
  }
}

[)amien

NotifyIcon context menus for both buttons in .NET (evolution of a hack)

Here’s the evolution of what should have been a clean reusable component in .NET and how it becomes a hack thanks to the limitation of the .NET framework.

Requirement

I’m working on an application where I want two contextual menus on the notify icon. The right one will display a number of options for settings and creating new items and the left to switch between the various items.

Before anyone else harps on about UI conventions this is exactly how the Windows Safely Remove Hardware notify icon works.

A brief glance at the NotifyIcon component in .NET shows that it supports one contextual menu displayed with the right button.

This is a shortcoming but not a problem right? This is a modern object oriented programming environment and extending functionality should be easy. It certainly was in Delphi back in the early 90’s with it’s .NET-like VCL framework.

Attempt 1. Sub-classing NotifyIcon (failed)

One of the founding principles of object oriented programming is reuse. The sealed keyword prevents reuse and forces use instead.

Keith Pleas wrote “If they extend it, they will break it. Use internal more. Seal first, ask questions later.” which is absolute rubbish.

In our case the sub-classed NotifyIcon would hook into the click mechanism and display a menu. Reflector shows nothing would break.

This is an unfortunate trend in the .NET Framework and with each release the framework grows towards an inflexible monolithic framework of simplistic classes. These classes force you to reinvent the wheel if they are not quite what you like because the developers believe they know exactly how you will use the framework.

Online forums provide substantial evidence to the contrary.

So creating a reusable component that just has two ContextMenuStrip properties – one for each button – is out thanks to short-sighted framework developers.

Attempt 2. Show ContextMenu on left-click (failed)

We’ll have to reproduce this code in each app we write and instead wire up to the NotifyIcon’s OnMouseClick event.

There we will need to test to ensure the left button is clicked and show the alternative ContextMenuStrip:

private void notifyIcon_MouseClick(object sender, MouseEventArgs e) {
  if (e.Button == MouseButtons.Left)
    taskMenuStrip.Show(e.Location);
}

Okay, this shows the menu now when the click happens but does not behave like the right-click menu. The positioning and click tracking is off and an odd blank task-bar item appears. A quick glance at the disassembly of NotifyIcon.ShowContextMenu shows code to handle the positioning and the the method we want to handle the tracking/task-bar is ContextMenuStrip.ShowInTaskbar.

And guess what? It’s internal.

Attempt 3. Hack the control (success)

Back at the drawing board we decide the only option left to us is the ugly hack. Replace the ContextMenuItem, call ShowContextMenu and then switch the ContextMenuItem back.

Of course even NotifyIcon.ShowContextMenu is unfathomably marked private so we’ll have to call that via reflection. The result is:

private void notifyIcon_MouseClick(object sender, MouseEventArgs e) {
  if (e.Button == MouseButtons.Left) {
    notifyIcon.ContextMenuStrip = taskMenuStrip;
    typeof(NotifyIcon).GetMethod("ShowContextMenu", BindingFlags.Instance | BindingFlags.NonPublic).Invoke(notifyIcon, null);
    notifyIcon.ContextMenuStrip = contextMenuStrip;
  }
}

Conclusion

The framework developers were worried I might break NotifyIcon if I subclass it and took measures to prevent that possibility through a combination of the sealed, private and internal.

Instead I am forced to develop a solution that is much more likely to break as I now rely on:

  • ContextMenuStrip property setter not clearing or removing existing displayed menu
  • ShowContextMenu private property not changing name or visibility

[)amien