Coffeehouse Thread

4 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Really dumb Whidby Beta 2 Coding question about defaultbutton property

Back to Forum: Coffeehouse
  • User profile image
    irascian

    I got my copy of "ASP.NET 2.0 A Developer's Notebook" today and thought I'd actually get around to working through it and becoming more familiar with the Whidby release I installed a few weeks ago.

    A few pages in there's a really simple example (it's in VB like all the book's code but I'm just rewriting it in C# as I go along) to demonstrate setting a default button.

    It doesn't work!

    I can see the property's set but no matter which button I set as the default it's always the Cancel button that lights up in the UI as being the default one.

    Am I being REALLY dumb here or can someone confirm that even this basic functionality is broken in Whidby Beta 2?

    Here's the source code of the web form (really simple! It's on page 16 if you've got the book)

    <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default2.aspx.cs" Inherits="Default2" %>

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

    <html xmlns="http://www.w3.org/1999/xhtml" >

    <head runat="server">

    <title>Untitled Page</title>

    </head>

    <body>

    <form id="form1" runat="server" defaultbutton="btnSubmit" defaultfocus="txtEmail">

    <div>

    Email

    <asp:TextBox ID="txtEmail" runat="server"></asp:TextBox><br />

    <br />

    Password

    <asp:TextBox ID="txtPassword" runat="server"></asp:TextBox>

    <br />

    <br />

    <asp:Button ID="btnCancel" runat="server" Text="Cancel" />

    <asp:Button ID="btnSubmit" runat="server" Text="Submit" /></div>

    </form>

    </body>

    </html>

  • User profile image
    W3bbo

    What does the generated XHTML look like?

  • User profile image
    Stitch 2.0

    irascian wrote:
    <asp:Button ID="btnSubmit" runat="server" Text="Submit" /></div>


    The first thing that jumps to mind:
    Where is that div opened??

    Don't know if it has anything to do with your behavior, but it seems strange...


    Nevermid..... just saw it...

  • User profile image
    irascian

    I didn't really want to get into that, to be honest because what code gets generated is of little interest to the main point. Which is that the UI is plain wrong, and it's the UI I'm interested in because that's what end-users (not developers) look at. The highlighting of the wrong 'default' button  will totally confuse an end user.

    Just so you know the JavaScript generated fires the submit button not the cancel button but that's NOT what the UI is showing me will happen and it's not what the book screenshot is showing me (it shows the Submit button nicely highlighted).


    My point, if I have one other than a rant Wink, was that this is a really simple piece of code that has come from a very basic exercise - drop a couple of text strings a couple of text boxes and a couple of buttons on the design interface and set a property to get rid of "the bad old days" of having to write a lot of hacky client-side JavaScript code to set the focus to the right input field and allow the user to see a default button and just hit the ENTER key as if he had clicked on the default button.

    Not much to ask for.

    But the UI gives totally the wrong idea of what will happen.

    Every new release from Microsoft I feel like Fox Mulder in the X-Files, repeating the mantra "I want to believe" but invariably I hit a really simple, really basic test within two minutes of looking at the product and find it hard to convince myself or anyone that there's any real quality control gone into the product when errors this basic are so obvious.

    This "bug" reminds me of my first encounter with .Net Windows Forms in the first beta when I dragged a label onto a form and a textbox onto a form and like most of my forms I chose the label to be right-aligned to abut onto the text box and chose a bold font. The end of the last character disappeared and could not be recovered because apparently nobody testing the product planned on having right-aligned bold text labels!  Yes there's a workaround (make the label left or middle-aligned and position it precisely, but why should I have to go through that grief?) Of course the bug was there in the final release, and still there in VS2003. This is pretty basic stuff not rocket science.


    The general impression of "quality control" left from experiences like this is very poor. Imagine you're doing a comparative analysis of products and you've got very limited time to do it. Bugs like the label alignment one and this one are very "in your face" and to me show poor QA.


    If you've seen that Monty Python sketch set in the restaurant where a punter goes completely over the top about a dirty spoon only to have John Cleese (or was it Eric Idle) enter and say the punchline "Thank goodness he didn't spot the greasy fork", I think this is where a Microsoftie enters stage left and says "Thank goodnes he didn't try and install Team Foundation Server" Wink

    On a happier note at least they've fixed the Windows Forms right-aligned bold label in Whidby Smiley

    Maybe they'll even fix Longhorn so that after you've told it you're in the UK and using English (UK) and a British keyboard it won't set the system clock to indicate you're in another part of the world completely!

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.