SDNET – all about .NET and computing

There are quite a lot of us who have a lot of papers on their desks with notes, tasks, observations. And there are those who use notepad alot to store usefull information on the project. Still it’s not easy to do this organization tasks when programming as it makes you either leave the development IDE or take your hands of the mouse and keyboard.

Why don’t we have a way to make quick notes within Visual Studio 2005. Well we actually do, although I have not seen any using it. Just go to the View menu and select Task List. A dockable window will come in front and you can dock it somewhere, I dock it in a group of windows below the code, so that it is easy accessible. How do you use it, well, just double click on the first available row in the list and enter your comments/tasks there.

For example, you have a task which is actually containing 7 inner tasks/functionalities. At some point you have to hardcode a variable so that you can go faster to another task and at some point you have to get back and correct this. This happens. No, no, don’t shake your head! you did it at some point. The problem is that you will likely forget this. Well, add a task like “Correct the hardcoding on file myfile.cs line 44″. At some point you will check that list and you can see what you still need to do and well … do it. Then just mark the task as completed (checkbox on the same line left side), or delete it.

No more yellow stickers and endless blocknotes

Cheers

Hi guys,

It’s been a while since I wrote a post here and that’s not because of a lack of good ideas but from a lack of time

What I want to talk about today is about an issues with MS.Ajax and IFrame’s. To be more precise, UpdateProgress and IFrames.

When a page contains an IFrame and both the page and the IFrame contain an UpdateProgress control, when an Ajax callback occurs, the Ajax engine tries to link the UpdateProgress control to the panel that contains the progress image.The problem is that you have two UpdateProgress controls and on the second one you would get an error in the  MicrosoftAjax.js file, more exactly in this function:

Sys.UI.Control = function Sys$UI$Control(element)
{
   /// <param name=”element” domElement=”true”></param>
   var e = Function._validateParams(arguments, [{name: "element", domElement: true}]);
   if (e) throw e;
   if (typeof(element.control) != ‘undefined’)
       throw Error.invalidOperation(Sys.Res.controlAlreadyDefined);
   Sys.UI.Control.initializeBase(this);
   this._element = element;
   element.control = this;
   this._oldDisplayMode = this._element.style.display;
   if (!this._oldDisplayMode || (this._oldDisplayMode == ‘none’))
  {
      this._oldDisplayMode = ”;
   }
}

The red code is where it crashes. So what is the sollution for this ? : use a single update progress, maybe in the masterpage if you have such thing.

 Cheers

There are quite some articles on this small issue but what I would like to post here is a more special situation.

This error occured while building a website in Visual Studio 2005 (the website was actually a port from an older Visual Studio 2005 WebSite Project). I could simply not find out why this error occured. It seemed that the compiler was building an object having a method or member with the same name as the class representing the page. In the codebehind file one could not pinpoint the problem, and then a coleague pointed out: “The form id has the same name as the class!”.

There you have it: in a ASP.Net 2.0 Website do not give the form object of a page the same id as the name of the page! otherwise you’ll get an error.

I was busy these days optimizing code for speed. What I found is no less than mind boggling. Using the right constructs one can speed up pieces of code tremendeously (read this like: a code that runs 10 minutes can be optimized sometimes to run in 10 seconds).

Tips:

Try to get data from the database in a single run. This is an old one but it seems people tend to forget this.

Carefull with the binding. With the advent of persistance frameworks, getting data from the database and binding it to controls became easy. Unfortunately due to design sometimes this gets in our way. For example, we have a business object called Person and which has a property homeadress of type Adress. In normal frameworks, the homeadress object is loaded only when it’s needed. So, we get a list of persons and bind this to a grid. And we say that one of the columns is actually a property of adress (person.homeadress.streetname). During binding, for each person, a call is made to the database to load the homeadress object and retrieve it’s streetname property. Thus for a 10 persons list we have 11 calls to the database (1 for retrieving the list of persons and 1 for each person to get the adress object). Try to avoid this !!! Use simple ADO objects of modified business objects instead.

Avoid find using predicates on lists. Searching using predicates is very nice and somehow natural but for large lists (1000+), the search time is high. Try using dictionaries for fast retrieval of elements.

Avoid List<T> and use Dictionary<T,Y> when making caches. This is an odd one, i did not digg deep into this problem but it seems that when creating a cache (parse a list, add the items) and afterwards accessing elements, for the same amount of data and the same logic, a dictionary was 10 times faster.

Use explicit casting when possible. The most common scenario is when we have a DataReader and we try to read data from it. If we know the first column is a string we could do it like datareader[0].toString() or (string)datareader[0]. And now the milion dolar question, what’s faster … take a wild guess . Also, don’t do int.Parse(datareader[0].toString()) if you know there’s an int, use (int)datareader[0].

… more to come here

About one year ago I wrote a small library which had as sole purpose the interpretation of the MethodBody.

What if this usefull for? Well using standard reflection mechanism from .NET one can find out from an Assembly what modules are inside, what types (classes, interfaces, enums, etc) and for each one can get the definition of the methods, fields and so on. Unfortunately when you get to retrieve the body of a MethodBase you stumble into a deadend. Microsoft does provide just a single method that can help: MethodBase.GetMethodBody. This returns an array of bytes that represent the body of the method. How in the nine hells can this be interpreted? We might want to know if a certain method is called from another method. By looking at an array of byte this task is dauting.

Still, if one looks at Lutz Roeder’s Reflector one can see that you can interpret this and even retrieve actual C# code from it. I managed to do something similar and the library I mentioned is a lightweight tool that creates a set of Intermediate Language instructions from the body of a method by looking at that array. I won’t get into details here because it is described pretty well in the codeproject article posted by me: http://www.codeproject.com/csharp/sdilreader.asp.

Check it out

Mnemonics – quick access keys that appear as underlined letters on buttons or menus and which are accessed by pressing the ALT key and the corresponding letter (the one underlined).

Read the rest of this entry »

I always hit a wall when trying to present the user with the possibility to enter a time (in format hh:mm or HH:mm). It ain’t an easy task and the sollutions are countless, but I won’t get into them. Instead I will unleash the power of the DateTimePicker upon you .

Read the rest of this entry »

A few days ago a coleague asked me to help him with a small program that generates a corporate email signature. The trick was that each user would have its own signature with the information being taken from its Active Directory account. At that time he was using a visual basic script that run from a shell and was using a XSL file for generating an HTML signature. It was an easy feat modifying the XSL to generate the wanted result but soon I hit a wall. How can you read a custom telephone

Read the rest of this entry »

I came about a nice article about how to write more comprehensible code. This does mean more faster or bug-free code, but instead more inteligible and more important more maintanable.

Short version:

• Comment like a smart person.
• Use #define a lot. No, a LOT.
• Don’t use variable names that will mock you.
• Do error checking. You make errors. Yes, you.
• “Premature optimization is the root of all evil.” – Donald Knuth.
• Don’t be too clever by half.