What are some good guidelines to follow when deciding whether or not to databind a control (for example, bind a combobox to a List)?
Are there situations where you should always or never databind a combobox?
How do you decide?
I measure it by how much manipulation of the data and its presentation I will be doing.
If it's light manipulation I'll just bind it, or at most do OnRowDataBound.
If I'm extensivelty maipulating the data, I'll spit it to a DataTable, manipulate it and Databind.
I always eventually databind() however.
Usually, if the data already exists in a datasource somewhere and that data has the potential to be kept up to date for the application's uses (through the application itself or by other systems/processes), I'll databind the control to that datasource.
Related
I have a gridview with checkbox control as a template field and one bounded field..
The grid is binded on every postback through a function and the grid contents remain the same on every post back..now when i check one of the checkboxes and then click the button at the end of the page, I need to store that particular row information..but I'm not able to retreive that information because when I check and then click button..the page loads and then the grid again populates and then checkboxes become uncheck and no CheckedChanged event fires..Help me with this
I need to persist the state of checkbox on every postback even when it is checked..how to do this??
In the page_load event function, please use the following code for your persistent data
if (!IsPostBack)
{
//your static data
}
This particular problem is fairly common. I haven't seen any "simple" solution yet, but here are 3 separate methods I have used. Each was used because of a limitation in the system.
Solution 1
Use AJAX. By putting your controls within an update panel, you can persist the changes by making them "real-time" in the database. This is not really a "simple" solution, but in my opinion it is one of the easiest to implement. Since the change is psuedo-immediate, there is no real need to worry about post-backs and persistence.
Solution 2
Use a "change management" control of sorts. You can apply a hidden control whose value is used to keep track of any changes made in relevant controls. You would need to devise a coherent data structure that provide at least a control ID and the new value (possibly the old value if you need some kind of "roll-back" feature). This would need to be coded in JavaScript so that any changes to the hidden control's value were structured and not duplicated. Then on your postback you would need to read this control's value, make any pertinent changes, and then rebind your data as appropriate. This can be fairly cumbersome, and it would need to be well-documented in the event that you pass this application on to a successor.
Solution 3
Use the PostBack for CheckChanged events and keep all data managed in the view state. During the RowItemCreated event of the GridView you can find the checkbox control in the relevant cell and manually add the delegate handler to that control to handle the postback in the event of a CheckChanged event firing. You can then have the change immediate. The drawback to this is that PostBack events become frequent and heavy. If you're storing large amounts of data in the ViewState this also causes page load to be slow and unresponsive, so whatever structure you choose for the ViewState you'll want to keep it small.
This is possible if you are using asp.net 4.0 using
<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true">
</asp:GridView>
If you are using 3.5, you will have to retain checkbox info in viewstate. I hope this will be helpful.
http://www.codeproject.com/Articles/202938/How-to-select-multiple-records-from-the-GridView-a
Another Option:
This is how msdn have described a hotmail type gridview.. may be this can help.. this will require you to extend existing GridView Control.
http://msdn.microsoft.com/en-us/magazine/cc163612.aspx
Regards.
Is it possible to update data in the datagrid without having to bind it to a particular object and still enjoy the benifits of a "two way" data binding? In this case the type of object to be binded is decided at runtime based on user input.
Some more clarity:
Actually I am using a multi threaded application and I need to update data in UI from another thread. For this purpose I share a reference for an Observable Collection object and bind(through ItemsSource) the same to the data grid. Now, whenever the thread updates the data, it calls a specific function in the UI thread asking it to refresh the datagrid. The problem arises when I try to modify some value in the grid so that it is sent back to the thread that is running in parallel. It throws an exception "'DeferRefresh' is not allowed during an AddNew or EditItem transaction."
With a DataGridView you can change the datasource at runtime and still enjoy two-way binding... Just set the DataSource to null first.
If for some reason you can't do that, you might consider object composition: i.e. binding your grid to an intermediate object which simply holds a variable for the actual object you're 'binding' at runtime, and create wrappers for the implementation (IList, IListSource, IBindingList or IBindingListView).
Unless I've missed something?
You can dynamically create a binding though code at runtime on bases of user input
Other than that I don't think that there would be any way to achieve two way binding without data binding. Once ugly way could be to handle data change event in both the itemssource and DataGrid and on the event update the other control i.e. data grid in case of change in itemssource and itemssource in case of changed value in datagrid, manually
When you set (not bind) the ItemsSource, bindings automatically happen at row and cell levels by internal implementation of DataGrid. So I am not able to understand "how" can we not bind an object to a datagrid and enjoy it's TWO WAY UPDATES.
They will anyways happen when u set the ItemsSource... or is it that you DONT want to even set the ItemsSource?
I'm binding to an ienumerable(items) in my MainViewModel to display data. As i've described here before How to change the content in a datagrid or listview using MVVM, all i want to do is display different tables. My first approach was to use the normal datagrid and set the "AutoGenerateColumns" to true, so that the correct columns are displayed. As it turns out, performance was pretty bad so i switched to ListView and GridView, but since there is no "AutoGenerateColumns" available i need to somehow create and change the columns.
So how would you do it?
Have a look at this question for something that comes close to -- but is not -- auto-generation: WPF GridView with a dynamic definition.
Generally speaking, autogenerating means doing reflection on the ItemsSource, which can get messy since it needs to cover a huge number of possibilities correctly.
I have a DetailsView control which gets data from a IEnumerable custom class.
But I can't get updated values from the control so I can process to update them manually in the database. How can I do that?
Regads,
Gustavo
I suspect it can't work with an IEnumerable... The DetailsView probably needs to be able to access the data source by index (or at least a way to access a specific item of the data source), so I think the source has to implement IList. But I can't find anything about it in the documentation, so that's just a guess...
It seems like some added clarification might be useful here, but some notes:
the DetailsView can work with an IEnumerable source (assuming you're setting DataSource to the enumerable), but it'll bind to the first item fetched from the source.
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.detailsview.aspx#binding_to_data
since it sounds like you're not binding to a data source, you'll need to hook up to an event (ItemUpdated in this case, I'd think) and then do the database update yourself
IMHO, if you can switch to binding against a 'real' data source life will be easier since you can let DetailsView do the heavy lifting for you, but if not, hopefully ItemUpdated will work for you :)
I read somewhere that one of few weaknesses in data binding model is that you never explicitly handle or create the data object that’s bound to the control and as a result you don’t have a chance to add an extra item. But I’m not sure what is meant by that.
What or how exactly would you be able to add an extra item if you were allow to explicitly create a data object? Would you basically be able to bind control to data source and let the runtime automatically fill the control with data source’s data , and additionally that control could also get an extra item from data source by manually creating it?! How would it be able to do that?!
thanx
When you use the OnItemDataBound event, you have full access to the underlying datasource object via e.Item.DataItem. You can use this data to populate any controls in the ItemTemplate via e.Item.FindControl("controlname"). You can also use functions inside the <%# %> tags to format text or calculate values.
What you have read, in my estimation, is pure crap. Up until the point of binding, I can alter the objects in question. One common scenario, for example, is adding a column to rows in a DataTable object (which is actually a collection of rows and columns). I can, in fact, alter by adding a column (let's say sum) to each row.
I can, with some restrictions on classes, do the same with other types of collections and objects.
After I have bound the object, I can still add items to the output by using the databinding method for a row, so I am still not restricted.
In general, I find those that are expounding this garbage are defending using ASP style code in an ASP.NET page.