>>>>>>>>>>>>>I think I'm really confused about how a web page works with respect to control event.s
>>>>>>>>>>>>>
>>>>>>>>>>>>>I have a textbox on my page. I want to know when the user changes something, so I dbl-clicked the TextChanged event - which
>>>>>>>>>>>>>doesn't fire unless the Texbox tag has the attribute AutoPostBack = "true" in it. At least, this is what's happening in my page.
>>>>>>>>>>>>>
>>>>>>>>>>>>>This of course causes the entire page to be reloaded.
>>>>>>>>>>>>>
>>>>>>>>>>>>>This is really screwy. I gotta be doing something wrong.
>>>>>>>>>>>>
>>>>>>>>>>>>That's how it works - the event has to be handled on the server. You really don't want to have the TextChanged event cause a postback (certainly not on an internet connection)
>>>>>>>>>>>>
>>>>>>>>>>>>>What if I want to collect data from 3 different textboxes, THEN send it all to the server. But I want to know when any field was
>>>>>>>>>>>>>changed? I'm not interested in firing off to the server when the user types, I just wanna know that they did type.
>>>>>>>>>>>>
>>>>>>>>>>>>Assuming that you did know that they typed something what would you want to do about it? (genuine question)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I have 3 fields on the page. There is also a Save button. When the user changes the text in a field, I want the button to become
>>>>>>>>>>>enabled. Even if it was already enabled, I would not want to push data back to the server that has not changed. So, to answer the
>>>>>>>>>>>question, I want to know that data has changed. I am trying to use the tetChanged event to store a mode as a session var so I know
>>>>>>>>>>>what happened.
>>>>>>>>>>>
>>>>>>>>>>>I'm wide open to suggestion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Put the 3 fields and the button in an AJAX updatepanel. Any events you handle will only result in postbacks for the fields and the button.
>>>>>>>>>
>>>>>>>>>A postback for every keystroke still seems a bit excessive ?
>>>>>>>>
>>>>>>>>
>>>>>>>>Actually I don't think the TextChanged event fires unless the textbox posts back (autopostback=true).
>>>>>>>
>>>>>>>Agreed. But what would be the point of hooking up the event if Autopostback wasn't true ?
>>>>>>
>>>>>>None. Autopostback has to be true for this to be worth anything. It still will only postback and fire the textchanged event if the user leaves the textbox and text has changed. It won't do it on each keystroke.
>>>>>
>>>>>I think we're drifting into a cross-purposes argument here. So:
>>>>>
>>>>>If AutoPostBack is true on the TextBox then postback will occur if the text has changed when the textbox 'loses focus'
>>>>>If AutoPostBack isn't set then something else has to trigger the postback.
>>>>>In either case if there's a TextChanged handler on the server that will fire if the text has changed.
>>>>>
>>>>>But with multiple textboxes on the page with AutoPostBack true that can be a lot of round trips to the server just to be told you're wasting your time. Agreed a panel can greatly reduce the volume sent over the wire - but you are still adding load to the server. If the logic to decide whether a postback can really be acted on can be encapsulated in the client why not put it there?
>>>>>
>>>>>Come to think of it isn't ASP.NET capable of generating a certain amount of data validation code in javascript on the client?
>>>>
>>>>There are lots of possibilities.
>>>>
>>>>What I'm suggesting works without adding playing with javascript in the mix. I've done this before in a bunch of sites.
>>>>
>>>>If this was google or ebay or some other high traffic site, this could be an issue. If this is a low volume site, this tactic is painless.
>>>
>>>I think that the solution to my problem is to put an Edit button on the page. Then I won't be relying on a TextChange event to determine
>>>when the user has changed something.
>>
>>For general editing of data, you might want to look at FormView controls. It's kind of nice to have something that lets contained controls bind to a datasource.
>
>Imagine that! ;-)
>
>Lots of talk here this week about the hit Ovechkin put on Brian Campbell on Sunday. If you didn't see or hear about it, Campbell had cleared the puck and was away from the play. Ovechkin drove him into the boards from behind. Campbell lay on the ice for several minutes and is now out for two months with a broken clavicle and rib damage. Ovechkin, who has been suspended for boarding before, was suspended for two games. Campbell will be out until mid May if not the rest of the season. The Capitals have not formally protested the suspension but have been complaining plenty. The coach said Alex was just completing the check. (My client was just completing the gunshot). He is by general agreement the best hockey player in the world but he is also a beast. Kind of odd when your top scorer and your enforcer are the same guy.
>
>Oh, and this is a good one. Someone with the Caps -- coach or GM, I don't remember -- said Ovechkin didn't cause the injuries, the boards did.

I've heard and read a bunch of commentary on it but I haven't seen the footage. I think I'll try to look it up tonight. Boarding really is a great way to end someone's career. I'm a firm believer that if it is done deliberately the hitter ought to be gone (like bye bye). Sometimes accidents happen though.