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.