What is a Non-CLS Compliant Exeception and why should I care.

While studying for Exam 70-316 (Developing and Implementing Windows-based Applications with Visual C#.NET and Visual Studio.NET) I found that the .NET framework has what is known as a “Non-CLS compliant exception”

While investigating this I found the following article on how to implement a bulletprof main routine:

    Sample of how to implement the main routine of an application.

Pop Quiz for Delphi developers : what is the most basic class that can be thrown as an exception?
The obvious answer of Exception is wrong – you can raise a TObject or descendant (TForm?)- just don’t expect your exception handers to work.

The .NET CLR has this great base Exception class.
So why do they need to allow anything else!
Why not define a ENonCLSException descendant and raise that!

It appears that IL allows a System.Object to be thrown in exactly the same way as Delphi!
The above link includes a sample of how do do this.

The moral of this tale is that your default exception handler needs to finish with a generic catch clause. I need to look into how to add my own template application to the defaults in VS.NET – some of these need to be created by default.

More usability issues

The .NET TextBox class when set to multi-line is a very weak control compared to Delphi’s rich TMemo control. TMemo exposes a Lines property to which a line of text can be simply added r individual lines manipulated. I need to look at the TStringList for C# to see if I can use it to create a fully featured TMemo for .NET.

            textBox2multiline.Text += System.Environment.NewLine + “This is a test”;

is far more code (and far less obvious) than:
 
             memo1.lines.Add(‘This is a test’);

In addition when you rename a delphi control if the text property matches the control then the text property changes as well. I wonder if the designer could be extended that far? This makes editing controls much easier – first you rename them and then you customise that into the correct text. This is far more efficient.

Replacement for ShellExecute

Try using:

System.Diagnostics.Process.Start

This is much cleaner than the PInvoke version of:

[DllImport(“shell32.dll”)]
public static extern int ShellExecute(IntPtr hWnd,
            string lpszOp, string lpszFile,
            string lpszParams, string lpszDir,int FsShowCmd);

static void Main(string[] args)
{
int hWnd;
long noth;

ShellExecute(0, “OPEN”, @”D:\WINNT\NOTEPAD.EXE”,
null, null, 0);

}

Useability issues

One of the reasons why Borland products tend to score above the microsoft equivalents is in the area of  small usability touches.

The .NET Framework has a LinkLabel control. The purpose of this is to allow hyperlinks &c.
However there is no desgner for this. You have to add the associated links in code.
While this is flexible it is more difficult than necessary to use for the simple case. Borland would have implemented the designer here.

Borland’s big problem has been marketing and sales.  Even when they have a superior  product they  cannot get the market to accept it.  Of late they seem to be diversifying into earlier stages of the lifecycle – requirements (CaliberRM), design (Together and Bold) and configuration/planning (StarTeam). It is difficult to complete against the Microsoft Universal licence (allowing access to almost all the development tools for a fixed annual fee) – Microsoft make their money off of the server products that the customers require. Borland could launch a product as a Visual Studio extender – adding in the missing property editors.

Microsoft Documentation

The .NET framework is surrounded by a lot of documentation.
However a lot of it leaves much to be desired.

There is a classic joke about a helecopter pilot that is lost in fog in Seatle.
He hovers near an office block and shouts out “Where am I?”
Upon hearing the answer “You are in a helecopter” he knows that he is at
Microsoft HQ’s documentation department and is able to fly diretly back to the
airport. The answer being both entirely accurate and completely useless.

This is a classic example. I have been trying to find out the purpose of
the EditorBrowsableState.Advanced option.

The documentation reads:

The property or method is a feature that only advanced users should see. An editor can either show or hide such properties.

This is again entirely accurate but completly useless.

The sample code that is linked to uses the EditorBrowsableState.Never option.
Why document the obvious case?

More Missing Stuff

Moving from the Delphi IDE to Visual Studio can be very frustrating.
While VS.NET is a real combine harvester in that it can perform a wider range of editing
than the Delphi IDE it seems to be lacking in some basic smarts that were in Delphi 1 ten years ago.

In Delphi when you rename the main form the equivalent of Application.Run is automatically updated. This may be a small thing but unless you want every app to have Form1 as it’s main form this is going to get rather old very quickly.

In Delphi when you leave an event handler empty (no code or comments) and build then the IDE removes it from the event handlers of associated objects. When you rename a control that has an event handler named after it the event is renamed and all of the IDE linked references are updated. If you have coded against it you need to fix these up yourself.

These are small things, but do grate.