Wednesday, April 14, 2010

Moving Blog (Again)

I don’t particularly like the idea of switching blog (again), however I’ve decided to join a few of my close colleagues (whom I respect a great deal) in a blog conglomeration of sorts. You can find my personal posts here:

http://sharpfellows.com/author/naeemkhedarun.aspx

And everyone’s posts here:

http://sharpfellows.com/

I did initially want to cross post but decided it was additional blogging overhead that I didn’t want, I’m lazy enough as it is :-)

If you are reading this, thanks a great deal for subscribing and I do hope you find the sharp fellows posts just as useful!

Nym.

Friday, March 26, 2010

Slower than Reflection: Take Two

This is a hugely belated reply to: http://kozmic.pl/archive/2008/10/13/slower-than-reflection-meet-stacktrace.aspx

I’m looking to perform some instrumentation on some already compiled code, and part of that involves getting a handle to a previous method. I wondered how slow accessing this through the StackTrace would actually be, and it turns out to be too slow according to that article.

I was hoping that Kozmic’s approach to getting the entire stack trace before filtering was causing the massive performance hit, so I did some benchmarks of my own…

Profile(() => new System.Diagnostics.StackTrace(false).GetFrame(1).GetMethod(), "Unfiltered StackFrame");

Profile(() => new StackFrame(1, false).GetMethod(), "Filtered StackFrame");

The unfiltered version is comparable to Kozmic’s example, and the filtered example is supposed to be more performant as we don’t need the entire stack trace. But the question is, “Is it faster?”. Let’s see:

image

(Results in milliseconds)

Yes it is!  However, quite unfortunately it is still not performant enough for my purposes. If you want to try out your own benchmarks the code is: http://bitbucket.org/naeem.khedarun/stacktrace.experiments/

Cross posted to: #Fellows

Wednesday, March 24, 2010

Session downloader for MIX 2010

I’ve rehashed the session downloader to be able to download the Mix 2010 sessions just gone by.

Thanks to Marcin Kaluza for helping out and giving the application some much needed design love.

image

As usual you can pick up the source at bitbucket: http://bitbucket.org/naeem.khedarun/fancypcddownloader2009/

And the download is now available via click-once: http://sharpfellows.com/SessionDownloader/publish.htm

Please let me know if you have any trouble with the application!

Cross posted to: #Fellows

Friday, December 11, 2009

Setting up and using KDiff in Visual Studio

One of the things that really sucks when using TFS is the integrated Diff and Merge tool which it ships with. I’ve tried out a few merge tools, and the one I was using previously was pretty good (I didn’t think a merge tool could get any better), and if you decide you don’t like KDiff then I would recommend giving it a try.

http://www.sourcegear.com/diffmerge/

Anyhow, a work mate recommended KDiff, initially I didn’t like the look of it. The user interface isn’t very inviting, if anything its rather intimidating. However once you get past its initial complexity its actually very simple and easy to use. Not to mention its quite powerful, and its three way merge algorithm is even more clever than TFS (its not hard tbh).

First download and install KDiff: http://kdiff3.sourceforge.net/

Next let’s set up visual studio to use it instead of the built in one, for both diffing and merging.

Go to tools and options.

image

Then select Source Control in the left pane, followed by the Visual Studio Foundation Server child item.

image

Hit the configure User Tools button.

image

Hit the Add button, and setup your comparison tool with the following data:

Extension: .*
Operation: Compare
Command: <location>\kdiff3.exe
Arguments: %1 --fname %6 %2 --fname %7

Next setup your merging tool with the following data:

Extension: .*
Operation: Merge
Command: <location>\kdiff3.exe
Arguments: %3 --fname %8 %2 --fname %7 %1 --fname %6 -o %4

Nice, you’ve setup KDiff as your default tool! The next post will outline some useful shortcuts and features.

Wednesday, December 9, 2009

Finding the root of all evil

Recently I was trying to fix a bug on a project I’m currently on, however in trying to fix it I found another 2-3 issues which I deemed more critical so I was slightly side tracked.

After fixing the other problems I returned to the bug I initially wanted to fix, only to find its already been fixed, great! Well it should have been.

The bug in question is when clicking a button on one of our wpf screens. A NullReferenceException was being thrown when attempting to load a dialog. The mischievous piece of code was this:

var startData = new ProductCodesDialog.StartData(hierarchicalCodeType)
{
DefaultSearch = productCodes.Trim().FinderSplit()
};

The problem? productCodes which is a string was null. This is fine and there’s probably nothing wrong with binding to null string values. But this piece of code was relying on the string being empty instead.

So the fix that I found nicely patched into place was the following:

if(string.IsNullOrEmpty(productCodes))
{
productCodes = string.Empty;
}

If something’s Null and we don’t want it to be null, then we just initialise it right? There was another piece of code in the actual textbox control which had something to say about that...

/*
* This fix below is for a strange issue whereby deleting all
* text in the textbox is not updating the source.
*/
if(Text != null && Text.Trim().Length == 0)
Text = null;

So this value is being constantly set to different values because dependant code is scared of throwing exceptions. Let’s take a look at what the value is initialised to so we have a starting point.

private String _value = String.Empty;

So whoever created the base type StringWithMatchType designed it with String.Empty being the starting value, IMO we should probably respect that as a heap of functionality has been built on top of this.

So why is it being set to null in the control? Apparently the bound object is not getting updated when someone selects all the text and deletes it. So let’s see if it’s the case... *a few minutes happened here* and to cut a long story short it does appear to be the case. So the new question becomes:

Why doesn’t my binding update to string.Empty when the textbox text is deleted? After a bit of Googling I found this:

http://jeffhandley.com/archive/2008/07/09/binding-to-nullable-values-in-xaml.aspx

So WPF is being carful not to null a bound property, not the ideal behaviour in this case. Ideally we want a string.Empty but perhaps WPF can’t be sure of what to do. Never-the-less luckily we are using .NET 3.5 SP1, and with that comes a handy binding property by the name of TargetNullValue

http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.targetnullvalue.aspx

So while this issue doesn’t affect the code above, as it’s binding to a string and does correctly propagate a string.Empty, it does affect some other places we are using the same custom textbox control. Wherever we are binding to Nullable<T> values seems to be affected, whether WPF doesn’t update the bound object when the textbox is emptied. I can only assume it was for this case the Text property on the custom control was being nulled. Using the TargetNullValue we are able to get around this:

WPFControls:TextBoxWatermark Text="{Binding Path=Value,TargetNullValue={x:Static System:String.Empty},UpdateSourceTrigger=PropertyChanged}"

And when retesting this the Nullable property is correctly being set to null when the textbox is emptied.

A dash of curiosity coupled with an inquisitive nature and a distaste for quick hacks seems to have got this problem resolved in quite a satisfactory manner!

Tuesday, December 8, 2009

Regex.IsMatch always returning true?

The following code was failing:

[TestMethod]
public void ShouldNotMatchInvalidCharacters()
{
Regex regex = null;
string invalidString = null;
bool result = false;

Story.WithScenario("matching invalid characters")
.Given("a regex expression",
() => regex = new Regex(@"[0-9]*\.{0,1}[0-9]*"))
.And("an invalid string",
()=> invalidString = "a")
.When("we check whether we have a match",
() => result = regex.IsMatch(invalidString))
.Then("the match should fail",
() => Assert.IsFalse(result));
}

It turns out it was matching on the empty string. I couldn’t think why on earth it was doing this. A bit of googling and the correct way to match on an entire string is to specify the start and end of the string in the regex.

^[0-9]*\.{0,1}[0-9]*$

The test now goes green!

Monday, December 7, 2009

PDC Downloader FileNotFoundException – Update 6

Big thanks to Sam for diagnosing and suggesting how to fix this one. It turns out System.Threading (Parallel Tasks Library) was not being copied in as a referenced assembly, I thought it was.

Anyhow – in the usual fashion, there's a new version:

download