Julian Jelfs’ Blog

Error connecting to undo manager of source file “blah blah blah”

Posted in Visual Studio by julianjelfs on March 31, 2009

This is just a note to self really so I don’t forget the solution to this problem that I have encountered a couple of times on Visual Studio 2008. The error message is always referring to the designer file associated with an aspx or ascx file.

To solve the problem you just have to delete the designer file, then right-click the associated aspx or ascx file and choose “Convert To Web Application”. All will be well again.

Tagged with:

Shrinking select lists in IE – jQuery.append bug?

Posted in jQuery by julianjelfs on March 27, 2009

I encountered a problem recently where I noticed that select lists with width set to 100% were mysteriously shrinking on me and I could only resolve the issue by setting a pixel width. This was a serious inconvenience since I have a fluid layout which is more or less ruined if I am forced to use fixed pixel widths. I found that others had noticed this issue here and here but there was no solution.

I set up a test with the following markup:

<div style=”width:300px”>

<select id=”shrinky” style=”width:100%”>

<option>One</option>

<option>Two</option>

<option>Three</option>

<option>Four</option>

<option>Five</option>

</select>

</div>


I also found, on closer examination that this seems to be a problem with using jQuery append in IE as demonstrated by the following test:

tf.AddTest(“Shrinking select list – demonstrates jquery bug”, function(test){

test.Expects(1);

var sel = $j(“#shrinky”);

var width = sel.width();

sel.append(“<option>test</option>”);

test.NotEqual(width, sel.width());

});

To show that this appears to be a problem with jQuery we can achieve the same thing manipulating the DOM manually and show that the select lists width does not change. This is demonstrated by a second test (notice the assertion at the end is flipped showing that the width is unchanged this time):

tf.AddTest(“Shrinking select list – native”, function(test){

test.Expects(1);

var sel = $j(“#shrinky”);

var width = sel.width();

var optn = document.createElement(“OPTION”);

optn.text = “test”;

sel[0].options.add(optn);

test.Equal(width, sel.width());

});

This alternative approach “solves” the problem for me in that I can still have 100% width select lists so my layout is not ruined. If I get the chance I am going to look into the way jQuery.append works to see if there is any obvious way to patch it so this alternative approach can become unnecessary.

Tagged with: ,

AJax.Net String.format update

Posted in Uncategorized by julianjelfs on March 27, 2009

I realised that I was using the debug version of the MS script libraries which skews the results quite a bit.

When using the release version they perform a lot better because a lot of the parameter validation that runs in the debug version is not done.

When testing with the release builds, my mind was put at rest on the array handling but there is still quite a big discrepancy between string concatenation and using String.format. Enough to persuade me it is still worth avoiding.

Also, even with the release scripts IE7 is still way worse than Firefox or Chrome (but we knew that…)

Javascript string concatenation performance

Posted in Javascript by julianjelfs on March 27, 2009

I was recently profiling some javascript code and began to suspect that the Microsoft Ajax.Net type extension String.format was causing some quite noticeable performance issue so I decided to run some tests to get to the bottom of it. The results were quite surprising.

Test 1 was normal string concatenation:

tf.AddTest(“StringConcat”, function(test){

test.Expects(1);

var start = new Date();

for(var j=0; j<10000; j++){

var str = “hello” + 1 + “hello” + 2 + “hello” + 3 + “hello” + 4 + “hello” + 5;

}

var end = new Date();

alert(end.getTime()-start.getTime());

test.Pass();

});

Test 2 was using the MS type extension:

tf.AddTest(“StringFormat”, function(test){

test.Expects(1);

var start = new Date();

for(var j=0; j<10000; j++){

var str = String.format(“hello{0}hello{1}hello{2}hello{3}hello{4}”, 1,2,3,4,5);

}

var end = new Date();

alert(end.getTime()-start.getTime());

test.Pass();

});

Test 3 was using a home made imitation of the MS type extension using regular expressions to fill in the blanks in the tokenised string:

tf.AddTest(“HomemadeFormat”, function(test){

test.Expects(1);

var start = new Date();

for(var j=0; j<10000; j++){

var str = format(“hello{0}hello{1}hello{2}hello{3}hello{4}”, 1,2,3,4,5);

}

var end = new Date();

alert(end.getTime()-start.getTime());

test.Pass();

});


where format is just a local function (which could easily be attached to the String prototype) defined as follows:

var format = function(tokenised) {

var args = arguments;

return tokenised.replace(/{[0-9]+}/g, function(matched) {

return args[parseInt(matched.replace(/[{}]/g, “”))+1];

});

}

Results for IE 7:
Test 1 : 328 milliseconds
Test 2 : 18626 milliseconds
Test 3 : 860 milliseconds

Results for Firefox 3.0.7:
Test 1 : 1 milliseconds
Test 2 : 6697 milliseconds
Test 3 : 431 milliseconds

Results for Google Chrome:
Test 1 : 8 milliseconds
Test 2 : 1958 milliseconds
Test 3 : 263 milliseconds

So, this is not particularly scientific and doing string concatenation in tight loops is not very realistic etc etc but a few things are pretty clear here. Firstly, simple string concatenation is by far the best approach. Secondly, IE performs a lot worse than the others with any approach. And thirdly, MS Ajax String.Format is a great deal worse than the homemade equivalent. Makes me wander what the other MS Ajax.Net script extensions are like …

Tagged with: ,

NHibernate – Setters of lazy classes cannot be final

Posted in NHibernate by julianjelfs on March 27, 2009

I noticed when running unit tests that I was getting the following error written to the console when building the NHibernate session factory:

2009-03-11 08:47:00,843 ERROR 7 NHibernate.Tuple.Entity.PocoEntityTuplizer – Setters of lazy classes cannot be final

What is curious here is that this is being logged as an error and yet everything is working fine. So what is going on?

The reason this error is logged is because when building the session factory nhibernate checks that each property is proxeable and, for various reasons it can conclude that it is not. In my case, the setter on the property is private. So far this seems to make sense. What is unclear to me is that if the setter is private and NHibernate is logging an error saying it cannot proxy the property, how come it works? My worry is that because Nhibernate cannot directly set the property it is forced to use reflection and therefore I am paying some performance penalty.

My “solution” is to simply make the property setter public (though protected or internal will do). This makes the error go away and I’m relatively comfortable with it because in reality my code deals with the interface which does not have a setter at all and so I’m not really exposing more data than I was before.

I would like ot have a clearer understanding of what is going on here though.

Tagged with:

Interceptor Selection with Castle Windsor

Posted in Castle by julianjelfs on March 27, 2009

As you may know it is possible to do some nice AOP type stuff by adding interceptors to objects served up using the Windsor container. It is also possible to inject interceptors on the fly using the interceptor selector extension point. I’m not going to talk about how that is done because that is very well described here.

I wanted to describe something that I thought was not obvious about the implemenation on this feature. I had assumed that if I returned false from IModelInterceptorSelectors.HasInterceptors then IModelInterceptorSelectors.SelectInterceptors would not be called. However, this is not the case. If the component already has interceptors, then IModelInterceptorSelectors.SelectInterceptors will be called regardless of what you return from IModelInterceptorSelectors.HasInterceptors.

This means that you really need to put your conditional logic to decide whether to dynamically inject interceptors into both interface implementations if there is any chance that the components already have interceptors.

This seems a bit wrong to me …. ?

A further gotcha is that the following approach for injecting an interceptor before other interceptors does not seem to work:

public InterceptorReference[] SelectInterceptors(ComponentModel model)

{

model.Interceptors.AddFirst(InterceptorReference.ForType<MethodProfilingInterceptor>());

return model.Interceptors.ToArray();

}

because it throws an exception in the CopyTo method of the InterceptorsCollection. I found that the approach in the linked article above does work fine though (presumably because it does not involve converting the Interceptor reference collection to an array).

Tagged with: