Site Sections
Posts
288
Comments
25
Trackbacks
207
November 2007 Entries
Getting the GridView Row Number for Custom Commands

This stemmed from a question on a mailing list and I had most of the answer, but have now discovered something that's now new, but is new to me.

When using a GridView you often have command buttons that perform some command on the row. Not the selected row, because selection is something different. generally I do this by giving my buttons a CommandName and handling the RowCommand event of the grid. The problem has been how do I get the row number and also the key value for that item in the row.

If you use a ButtonField this is easy, because the ButtonField automatically sets its CommandArgument property to the row number; when you think about it, you can set the CommandName of the ButtonField, but not the CommandArgument; why not? Because it's set for you. Yeah, who knew? In the RowCommand event you can then just extract this with:

int rowNum = int.Parse(e.CommandArgument.ToString());

If you're using a templated field, there are two ways. The first is to set the CommandArgument yourself. For example:

<asp:TemplateField>
    <ItemTemplate>
        <asp:Button ID="IncreasePriceButton" runat="server"
            Text="+10%"
            CommandName="IncreasePrice"
            CommandArgument='<%# Container.DataItemIndex %>' />
        <asp:Button ID="DecreasePriceButton" runat="server"
            Text="-10%"
            CommandName="DecreasePrice"
            CommandArgument='<%# Container.DataItemIndex %>' />
    </ItemTemplate>
</asp:TemplateField>

Here DataItemIndex represents the row number. Within the RowCommand you can extract this in the same way, just getting the value from e.CommandArgument. If you can't use CommandArgument, perhaps becuase you need it for passing in other types of data, then you can still get the row number, but have to do a bit more work:

int rowNum = -1;
GridViewRow row = ((e.CommandSource as Control).NamingContainer as GridViewRow);
if (row != null)
{
    rowNum = row.RowIndex;
}

It's not quite as elegant, but works just as well.

posted @ Thursday, November 22, 2007 10:56 AM | Feedback (1)
In Search of Carbon Worth

The old paper v. e-book debate has started again, with the release of several new e-book readers. The publishing industry has been playing with this for years, but it's only now that the technology is making it viable. I don't deny there are some great benefits from them, but I'm not convinced they outweigh the downsides. Here's my view and yes, from my point of view there are only two good points:

Pros

  • Density: you can carry multiple books.
  • Searchability: useful for reference books.

Cons

  • Battery life: I've yet to have a book not work because of battery failure.
  • Lifespan: Charles Petzold puts it well; I still have books I bought in the 70's.
  • Density: each book is standalone; if I carry two, I can lend one to a friend.
  • Flickability: I've just made that word up, but it describes what I mean well; you can easily flick backwards and forwards in books.
  • Digital Rights Management: Will my e-book continue to work if the reader is replaced? If I want to read it on my computer? If I want to lend it to a friend? If the DRM server is switched off? If you're in a country not supported?
  • Emotion; there's something much more tangible about paper, more evocative. Maybe it's nostalgia, maybe it's not moving with the times.

There's an interesting debate at 37signals. Julia also has a few words - I particularly like:

I love the different fonts that are created for letter presses. I love the varying quality of the covers and the paper. I love the feel of the paper.

I too feel the same. I love books and have done since very young. I spent most of my childhood reading and most of my pocket money on books. There are only two books I've started that I've never finished: Catch 22 by Joseph Heller, which I must try again; I think it was just not being in the right frame of mind for it, and Mansfield Park by Jane Austin, which was dull as Mr Dull from Dull City in Dull Land who'd just won the contest for being the dullest person on the planet. Sorry Jane, but you know I'm right (friend Jane, not Ms Austin). I also don't think I've thrown a book away; I have boxes and boxes of them filling up the dining room. Some are better than others, some probably not worth keeping, but Gunter Grass said it:

Even bad books are books and therefore sacred

I'll never feel that way about an e-book reader and disposable text. Despite my love of gadgets, it's carbon based technology for me.

posted @ Tuesday, November 20, 2007 11:39 PM | Feedback (0)
FormView ModeChanged Event

Something I've just discovered upon using the FormView is that the ModeChanged event is not useful for accessing the controls within the template of the new mode. It seems the obvious event, but it's really only a notification that the CurrentMode has changed; the control collection is still under construction, so the controls of the new template aren't available. Any controls you do access (using FindControl of course) will be from the template of the previous mode, not the template of the new mode.

To access the controls in the current template, when the template has changed, you should use the ItemCreated event, checking the CurrentMode to ensure that you find the correct controls.

posted @ Wednesday, November 14, 2007 5:23 PM | Feedback (0)
Ajax Web Parts

I like Web Parts, really I do. Their functionality is great, but I find them a bit heavy; the HTML they generate isn't great and some of the customisation is dated now that Ajax is popular. In fact, I can't help feeling that if the ASP.NET team had to write Web Parts from scratch now, they certainly wouldn't take the same route; they'd be Ajax based all of the way.

There were many ways in which I could have improved the existing functionality of Web Parts, but it just didn't seem sensible given that the things I don't like about them are inherent in the framework. I'd also proposed a session for ASP.NET Connections where I'd compare and contrast WebParts and Ajax, and it seemed contrary to the idea of the talk to change the server-side functionality, when I should be looking client-side.

So I decided to create a client-side framework, and spend a bit of time playing around with ideas until I found a good base to build on - Rick Strahl's wwHoverPanel. Rick is a fellow MVP and conference speaker and has a great set of Ajax controls; server controls that are just containers for a small amount of content and that emit JavaScript to encapsulate the client side functionality. Rick's framework has a drag panel, which supported close, but not other things that I feel are needed; minimise and maximise, state persistence, connections, etc. So, as his source code is available, I started hacking. I got the min/max and persistence (to the ASP.NET Profile) working before the conference, but hadn't really done much in regard to connecting the parts together. I started telling Alex about this in the bar one night and we argued for a day on how to do it; I'd started off thinking in the same way as Web Parts, but registering both a provider and a consumer to allow data to flow. Alex, who has been writing a log of documentation for the Microsoft Patterns and Practices group, suggested a form of the observer pattern would be better, given that it more naturally fits with developers used to subscribing to events. So I tried it and it worked well, with a consumer part registering to receive data; the registration uses a key to identify the sort of data (ZipCode, Address, etc) and is not type related - it can be a simple type (a string) or a complex JavaScript object, there is no restriction. Any other part, or any client script in fact, can just send data using this key to identify the targets. It doesn't know what the targets are, just the key.

The project is available on the Ajax Web Parts page on my site and is free to download and use as you see fit. It's very raw at this stage and there are things I intend to do to improve it, such as cleaning up some of the code, removing some hard coded names, fixing some bugs and adding features.

posted @ Monday, November 12, 2007 1:09 PM | Feedback (1)
Article Categories
Archives
Post Categories
Image Galleries
blogroll