Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

More .Net inconsistencies, ASP this time

Have you noticed that in ASP.NET, the CommandArgument is a string property on the buttons, but an object on the event argument parameter.

Now I am forced to a (string)e.CommandArgument or an e.CommandArgument.ToString() on something that can't be nothing but a string.

How did this slip QA? Or is there a deep secret I don't know anything about that make this a perfect sence?

Thomas Eyde
Friday, October 03, 2003

Yea ok Thomas, whatever. All your little nitpicks are not exactly showstoppers are they?

Scroll to the bottom of the relevant documentation page and click the "Send comments on this topic" link and tell the people who can do something about it. I've heard they do actively monitor the email alias too incase your cynicism would prevent you doing that.

Pedant-phobe
Friday, October 03, 2003

Showstoppers, no. Needless annoyances yes. I care about quality and coding speed. I always forget the event property is an object, not a string. Besides, I think Microsoft is aware of this by now. They have to use their own product, at least for writing docs and articles.

But what can they do? Changing the property type to string would break some peoples code, won't it?

Thomas Eyde
Friday, October 03, 2003

>> But what can they do?

They can consider changing it for the next verson of .NET

Pedant-phobe
Saturday, October 04, 2003

They may be allowing for other controls (or user-defined classes) to use the same event. You could write a class control that returns an Int32 as a "CommandArgument" and use the same event infrastructure.

My guess is they were thinking of catering for a String and an array of Strings, at least.

Mark Hurd
Wednesday, October 08, 2003

If you are right, then this is another example of thinking ahead not always get you where you want.

All CommandArguments so far are strings. So here's a feature we don't need.

What if we sometime in the future need string arrays? No problem, use the QueryString approach: Add a method called GetValues(). It's typesafe and the unneeded typecasts are gone.

Thomas Eyde
Wednesday, October 08, 2003

*  Recent Topics

*  Fog Creek Home