brady gaster

Renaming (or not renaming) Objects in HTML Design View

There are a ton of weirdo behaviors when using the VS.Net 2005 IDE, especially in the HTML-editing department. Someone in the IDE team apparently came to the conclusion that real developers never use WYSIWYG tools any more. On the contrary, a lot of real developers use such IDE's so that they can spend their time writing the real code, not the HTML code. I'm one of those cats, and sometimes I like to change the names of the objects I place onto my pages. Names like ObjectDataSource1, ObjectDataSource2, and so on, tend to not make as much sense to me as do names like dsAuthors and dsPublishers. So, I drag an ObjectDataSource onto a page, then click it, hit F4, and edit the ID property. First I get a dialog that tells me that any other markup referencing this object will break so I should think twice before doing so. If I click OK, expecting a few screen-flashes and then a changed ID, then look at the ID property in the grid, guess what?

Nothing happens. I clicked OK. I've tried it clicking Cancel, too. If you see that dialog, your ID won't be changed. Check your exception-handling and UI-validation routines, boys and girls, you missed the boat on this one.              

Support Complaint

So my company filed a support call with MS support regarding the "bloody forehead" issue I ranted about a few weeks ago. I received an email telling me that the "case is closed," despite there being either a workaround or a viable solution. Apparently, the fact that I told them "we can work around this because we're writing our own business tier anyway" was a good enough excuse for them to close the case. Guys, I don't think this is a sound practice. If your customers have to find workarounds to solve problems yielded via your toolset, claiming that the problem is by-design isn't anything remotely resembling a solution. I wouldn't have had to find the workaround had your stuff worked in the first place, now would I? Call me crazy, but it makes sense that you fix the issue, provide a legitimate workaround, or at least offer some helpful hints or solutions to the issue. Don't just say "oh, they solved their own problem," when the problem is "changing the way you code because the IDE doesn't do what it says it does."

More Complaints {though not from me}

Apparently I'm not the only one who's complaining.

Empty GridView, Invisible Footer

My current project involves a few GridViews. We're going with the "add new row" technique, and placing the form for the new row in the footer of our GridView. So if the GridView has three columns, first, last, email, the footer would have three textboxes to collect that data with an add button or something. Got it?

Well, that's all well and good if you've already got data in your database or your GridView. If you don't you're totally screwed, because the footer won't even show up. I've seen a few suggestions on how to accomplish this thing, but none of them really appealed to me. One suggested that your stored proc always return a null row. Not going to happen in any real-world shop, of course, so its up to your code to accomplish this amazing feat. In my situation I'm using ObjectDataSources and DataSets, so I have a moderately agreeable solution.

Create an Event Handler for the ObjectDataSource's Selected event.
Within that handler, add a new record to your source. In this way, you've added a row to the local data store store just prior to binding your GridView. Since the GridView now has a row in it, the footer (and header) will show up. Hoakie though it is, it solves the problem created by an even hoakier decision made on the part of MS's control team - to hide your header and footer if you have no data. 

protected void OnPeopleDataSourceSelected(object sender, ObjectDataSourceStatusEventArgs e)
{
    MyDataSet.PeopleTable dt = e.ReturnValue as MyDataSet.PeopleTable;
    if (dt.Rows.Count == 0)
    {
        MyDataSet.PeopleRow row = dt.NewPeopleRow();
        row.First = DBNull.Value;
        row.Last = DBNull.Value;
        row.Email = DBNull.Value;
        dt.Rows.Add(row);
    }
}

.Net 2.0 Complaints

I'm sick of .Net 2.0, the bugs in it, and the architectural mistakes and missteps that I find each and every day in the new framework. I thought I would get something good, but I didn't, and I'm pissed about it. I don't want to be a kvetcher like this, so here's how I'm going to spin it. Instead of just kvetching about .Net 2.0 problems and bugs and things that just plan out suck, I'll do my best to explain each thing as I find it. Where possible (and it isn't always), I'll even show how I resolved the issue at hand. I figure, (a) MS isn't doing anything about the problems I'm reporting to them, (b) if I'm seeing these things I'm sure someone else is seeing them too and therein not getting any help as I'm not. So I'll do my best to provide some solutions for these problems. Call it community involvement if you want, call it being a good sport or a bad sport, but the bottom line is that the framework is broken and there's a lot of people out there trying to make things happen and failing miserably as a result of there being shortcomings in the framework. The miserable failure will continue to happen because MS is more concerned with releasing a new framework than they are fixing the one they just released. So I'm going to try to show everyone how to work around the problems as I find them. I don't want a medal, I wouldn't accept an MVP, and I sure as heck don't care what anyone thinks about my persistent kvetching. 

 So that's that. I'll create a new category (or a tag or something) to make your life easier, in case there's anyone out there who's interested in keeping track of how I solve these problems as they arise. 

In NC? Like to work? Need a better job?

If so, and you're experienced at ASP, ASP.Net, and so forth/so on, shoot me a note. Job would be located in Charlotte, NC, working for a relatively large (600+) dot-com company that's pretty awesome. Best job I've ever had, retardedly good benefits, good pay, and an amazingly cool work environment. Safe and sound, fun, great location. Shoot me a note!

Outcome of the Forehead Issue

Well, there wasn't ever really any outcome. I ended up speaking to MS and there isn't any known fix for this problem. Apparently it was a bug that'd been found in the beta release that had been reported as "fixed" prior to the true release. Well, problem wasn't solved, and the [very helpful] support people have confided in our team that they'll let us know if and when the issue is resolved. Good going, let's hope its soon.