I'm trying to bind my GridView at runtime, but I'm also trying to avoid running all the binding events twice.
I have a GridView that gets populated from a function that returns a DataTable. I'm not using ViewState in the grid for a couple of reasons. I seem to have a Catch-22 situation here:
If I don't bind the grid by Page_Load at the latest, the RowCommand and other grid events won't fire.
If I DO bind the grid in Page_Load, but I'm on a PostBack from a pager link, sort link, or search button, those event handlers will change the data and need to rebind it, running all the binding code again.
The grid triggers DataBound, RowDataBound, and RowCreated events, which could be performing expensive operations. I really hate to call them all in Page_Load, and then wipe out the data and call them all again if the data changes. But I can't seem to avoid this double duty, because in Page_Load I don't know if it was a grid event that will change the data, or a grid event that doesn't.
Any ideas?
Try the command arguments. If a button in the gridview was clicked, that event will be fired and you can handle it appropriately. Your question is not clear enough i'm afraid. Could you be more specific?
Check if request is a postback. Bind the datatable to the grid like so:
If(!ispostback)...
That way you wont be binding the table to the grid on each request.
Related
Im working on asp.net with c#.
I have a gridview with templatefield columns, data comes from an sql database. I have linkbutton on the item template, the linkbutton calls the Rowediting event to enable the editing. This works fine on the first row. But when I click on any of the other rows nothing happens, the event never gets fires.
How can I solve this?
Thanks..
Most likely you are data-binding the grid in the Page_Load event. If this is the case, the ASP.NET Page Lifecycle is getting in your way. (Be sure to read the article in the link provided. Every .NET developer needs to know about the Page_Lifecycle. It explains a lot of behavior thaqt would otherwise cause confusion, such as this behavior.)
The Page_Load event happens on every postback - every button click, or any event that triggers the postback.
If this is the case, there are two possible options:
Move your data binding code to Page_Init
Put your data-binding in Page_Load inside an if(!Page.IsPostback) block.
In essence, the problem is that your page is data-binding on the first load.
Then the editing event is triggered by some client action, which triggers a postback. In this postback, Page_Load fires first, which re-binds the GridView, erasing all of the data that was associated with it on the previous load. So when the RowEditing event fires (control events always happen AFTER Page_Load) there's nothing for it to do. All references to the data as it existed before postback are gone.
If you move your binding code too Page_Init, you can get around this because the page will be bound, and then all of the Viewstate will be re-applied to it, restoring the data that was lost in the postback in the scenario above.
I have a gridview with checkbox in Itemtemplate. What i need to do is check the condition:
(checkbox.checked==true)
if its true take the rows to another gridview. i binded the data of the gridview in
if(!PostBack)condition.
Everything was working fine until my employer said he doesnt wants the gridview to be bound in the if(!postback) condition but if i take that condition out checkbox.checked value is false always!
From the details of your question, I'm not sure if your boss wants the grid unbound or doesn't want the page bloated with the grid's ViewState, but in my experience, it's usually the latter. However, if your boss simply doesn't want the grid bound in the "if(!Postback)" condition and doesn't mind if it's bound or uses ViewState, then your boss doesn't understand web development using C# and server-side controls.
But... to answer your question, the reason the checkboxes are all unchecked is because you're rebinding the grid AFTER the ViewState has been applied. ViewState contains all the data needed in a postback condition to set the state of the checkboxes during postbacks and applies that data prior to the OnLoad (or Page_Load) event. By rebinding the grid, you are essentially wiping out anything that was posted back in ViewState and applied. To overcome this, turn ViewState off for the grid and apply the state of the checkboxes yourself AFTER you rebind the grid using the FORM collection.
If you want to do away with ViewState, here are some tips in this article.
http://www.codeproject.com/KB/viewstate/DataGridViewState.aspx
I have a Repeater nested inside of a GridView. On the RowDataBound event for the GridView, I set the DataSource (based on one of the row's columns) and then bind the Repeater. This works fine for the initial load, however I need to be able to add new items to the Repeater dynamically.
I append an item to the DataSource, save it to the ViewState, and where I would normally bind using a method call, I bind to the object saved to the ViewState instead. The DataSouce reflects the change, however the page does not.
What am I missing? I have the exact same setup on another page without the nesting and it works perfectly.
if (ViewState["RepeaterObj"]!=null)
{
rpt.DataSource=(IList<DataTransferObject>)ViewState["RepeaterObj"];
}
else
{
rpt.DataSource = controller.GetObj(param);
rpt.DataBind();
}
I ended up resolving the question by cutting out use of the ViewState entirely, though I thought my temporary DataSource would be lost across the postback it wasn't. I ended up going with a class-level variable which works perfectly. It seems I didn't properly understand what happens during a postback.
First of all, you shouldn't be storing a datasource in ViewState. That's pretty much the worst place you could put it.
As for your problem, I would suggest either rebinding the GridView when new items are added to the repeater, or find the repeater in the event that saves the new record and rebind it there.
I think the problem is you are not rebinding the the Repeater. You say you change how you bind to look at the ViewState object but are you actually triggering the Bind to occur? It sounds like you are not and the page is just reloading with the current data stored with the control's ViewState.
Make sure you are calling your Repeaters bind event explicitly to sure it is getting rebound.
EDIT: I suspect it might have something to do where you might need to rebind your GridView and not just the Repeater.
I have a question about button inside the gridview. As the title says, I designed a gridview with a button inside. Whenever I trigger the button, it always binding the gridview before it can reach the button event.
Say, onLoad page, I pull data and bind them to a gridview, then I would like to do a mass update which will be triggered by the button inside it. If i put !IsPostBack, it never triggers the button event, which means it always has to read the data bind them into gridview again then execute the button event.
Problem is, I have a huge data and it takes much time to update because of it. I am wondering if there are any ways to trigger the button event without rebinding the gridview again? Is it because of the button inside the gridview so it is necessary to rebind again before it could read the button event?
Any suggestion would be really appreciated.
Why don't you use the RowCommand instead of the onclick event?
you can add a command name property to the button to understand what operation you need to do
Have a look at the link below and just replace the ButtonField with a classic button. don't forget to assign a CommandName
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.gridviewcommandeventargs.aspx
You should not use the button event, but the GridView.RowCommand event instead. See here. If you do this in combination with the if (!IsPostBack) check in Page_Load, it should work for your scenario.
your button must be triggered by OnRowCommand event and ! IsPostBack shouldn't prevent triggering your button
protected void GridView_RowCommand(object source, GridViewCommandEventArgs e)
{
if(e.CommandName=="Update")
{
// put your update code here
}
}
and you can use ajax to update your datasource without rebinding your GridView and update your UI using javascript.
On an ASP.NET page, I have a GridView populated with the results of a LINQ query. I'm setting the DataSource in code, then calling DataBind on it. In the GridView's RowDataBound event, I'm selectively hiding links in some GridView fields based on the query results. (For instance, I hide the "Show Parent" link of the row in question has no parent row.)
This works fine initially. But on postback (when I don't call DataBind, but the GridView stays populated through ViewState), the data displays, but the RowDataBound event (obviously) doesn't fire, and my links don't get hidden.
What's the best way to get the links to be hidden after a postback?
The RowDataBound event only fires when the GridView's data changes during the postback. The event is short-circuited for speed so it's not re-generating the exact same data unnecessarily. Use the RowCreated event to manipulate the HTML instead - it fires on every postback regardless of whether the data has changed.
Here's how I ended up solving this:
I created a serializable class with readonly properties: PK of a row, and a boolean for each link indicating whether it's enabled or not. We'll call it LinkVisibility.
I created a serializable class inheriting from KeyedCollection to hold instances of the class above.
I created a ViewState-backed property holding an instance of that collection.
In my Search procedure (populating the GridView), I clear the collection.
In RowDataBound, which initially shows/hides the links, I add a LinkVisibility instance to the collection for each row.
In Page.Load, when IsPostBack is true, I loop through the GridView rows. I look up the LinkVisibility for each one by PK in the collection (DataKeyNames is set in the GridView), and I set the links accordingly.
I don't know that this is the best way to do this, but it certainly does work, which is more than I can say for anything else I've tried.
1) You could have a Method - ProcessDataRows() that would get called once on grid_DataBound(...). And then when you need it after PostBack.
And that way you process all rows when you want.
2) You could have methods like ShowParentLink(). That are then bound to the LinkButton in the grid (if you're using an ItemTemplate) and the link would have
Visible='<%#ShowParentLink()%>'
I would have expected the viewstate to also reflect the fact that you have removed some of the links (assuming that they were removed before viewstate was saved).
Maybe thats the question you need to ask 'why do the removed links still appear in viewstate?'.
Another solution is to put the logic in the LINQ query, so that you end up with a boolean LINQ field like "ShowParentLink". Then you can just bind the Visible property of the HyperLink field to that value - no RowDataBound required.
protected void btnHazardRating_Click(object sender, EventArgs e)
{
gvPanelRole.RowDataBound += new GridViewRowEventHandler(gvPanelRole_RowDataBound);
gvPanelRole.DataSource = dtGo;
gvPanelRole.DataBind();
ModalPopup.Show();
}
void Process Rows()
{
... do something
... process complete
datagrid.DataBind();
}
A page cannot process postback events unless it is rebuilt exactly as it was before (the postback). If you re-hide your links during the page-init, then your click events and such should fire. Unfortunately, without seeing some sample code I can't get more specific.
Also the data RowDataBound does not fire because you are not data binding. You are rebuilding the page from the viewstate- "viewstate binding" for lack of a better word.