I wouldn’t say I know AJAX. I use it for the modal popups, and update panels to remove flicker. I guess event was not thr right word. Because if you use a normal .Net event, you always get the top most radio button list. What I did was add an attribute, onclick, to each radio button list as it was put into the GridView that called a JavaScript function. The goal was to do as much of this on the client side as possible, post backs are slow.
That is not AJAX. That’s just using JavaScript on the client side. Since postbacks are slow, this makes sense as you found out.
Finally, some one thinks I’m smart :tong The looping worked for awhile, but then instead of having 50-100 rows of data on a page, some companys ramped up and are now needing 500-1000 rows a page. Also, since this looping is on the client’s machine, there is no way to ensure its fast, even if I unroll the loop, because they could be on some POS from 1990.
We can talk about this forever as it really depends where the bottle neck is: the search execution, the download, or the page rendering. There is a TON of ways to resolve this problem.
As I mentioned earlier, I mis-spoke and I’m adding an attribute, not event handlers. I figured out that on each page load, even if I don’t reload the GridView, the onclick attribute is being dropped from all the buttons. This is weird to me because I have a couple other buttons that work the same way (I add the onclick attribute at run time via code behind) and they have always worked.
Technically, you are wiring events as you are wiring up the “onclick” event. However, you are using “attribute” because that is used for the HTML controls on the client side (vs .NET’s OnClientClick event equiv for server-side controls) where as the onclick is ASP .NET’s (server side controls) is handled on the server (postback occurs).
Now that I think about it, I add the attribute to those buttons in PageLoad. Thats why they have always worked.
Yep. They always got re-wired up.
The data I use to build the controls’ onclick attribute is a RowDataKey from the GridViewRow, and the value of the control. The database is only hit on initial page load and when the user wants to view a different date range.
[/quote]
How is the data stored for subsequent page loads? Is it stored in View State?
I am using the base .NET GridView :headbang
I use RadControls by Telerik. Not too pricey but they are damn impressive. They are hefty if you look at the CSS/JavaScript but functional.
What I did was create a method that re-wires everything after a user ‘verifies’ a row. That post back resulting from that is the only postback in which the grid is not reloaded (and hense everything being setup right).
Makes sense
Well, I want to put more time into it as I see the re-wiring as a hack. But the page load time varies based on the amount of data being pulled from the database. Ideally we want it as fast as possible.
The re-wiring isn’t a hack if you consider ASP is a disconnected application. You lose state as soon as the server delivers the response back to the browser. It has no idea what’s going on until a response is sent back to the server.
Consider this: You add a server side control to a page such as ASP:Button and then specify the OnClick event. You go to the code behind and handle the event accordingly (BTW, I use C# but I can translate to another .NET language if you prefer): protected void btnSave_OnClick(object sender, eventargs e) …
You then expect that event method to get called when you click the btnSave button. It only does because the button is WIRED UP. If you check the page declaration you might see this:
<%@ Page Language=“C#” AutoEventWireup=“true” Title=“Shawn August’s Guestbook”
MasterPageFile="~/BASE/BaseMasterPage.Master" Codebehind=“guestbook.aspx.cs” Inherits=“ShawnAugustDotCom.guestbook” %>
That handles the re-wiring every page load for controls that are added to the ASPX. If you don’t use that attribute, you need to do the wiring yourself every time the page re-loads. How else would the server know that you want x control wired to y event?
With that said, this is where it becomes tricky because a lot of run-time controls are data driven meaning you need to get the data from soemwhere which is often an expensive database hit or such. You can store that data locally via View State and rebuild the page (because you need to re-wire the events).
For example,
page load
database pull -> get # of trips from database
save database pull in ViewState
display trips within gridview control
add controls as necessary and wire them up
page re-load
check if saved database pull exists. If not, re-grab data
display trips within gridview control
add controls as necessary and wire them up
In this scenario, you do not make a database pull.
)
i’ll read the thread in a couple hours cuz i have to fix a stupid pc right now, then if u havent solved it maybe i’ll give it a go 
sucks… but w/e i got crysis warhead to test it out benchmark wise but thats about it ahaha