Hi Kevin,

I appreciate the time you have spent trying to help me with my UI issues. I look forward to using Infragistics controls but for now I’m just trying to master the basics of Asp.Net and MM.Net.

I think I am close to solving my original problem of binding to a specific row of a dataset on a postback, not using a gind but by binding to textboxs and other controls. Instead of binding to a datarow( where I ran into problems), I have written a surrogate biz obj that can be used as the bindingsource for ONE row of another dataset containing detail rows. The biz obj clones the original dataset, adds the specified row# and calls the binding events. For bindback the row is copied back to the original dataset. On save, parent and detail records can be saved in one transaction. It is instantiated like any other biz obj and binding properties are set in the property the sheet. However the data is created on the fly from a row in another dataset. The code is completely generic so it can be easily sub-classed.

There are several UI methods were this technique can be used and I will follow-up with details once I have tested it a little more.

Again Thanks for your help.

Terry Carroll




>Terry,
>
>Ultimately, I think the bottom line here is that what you're trying to do is best accomplished by a control like the Infragistics DataGrid that allows in-place editing and batch-save abilities. This is actually one of the key reasons I'm going through all the pain of this integration now. The out-of-the-box controls that are part of ASP.NET (and from which we've created subclasses in MM .NET) are very limited in their scope. This is why companies like Infragistics are doing so well.
>
>What the Infragistics grid is doing is no small feat and would be difficult to replicate--they provide much better event hooks for the entire batch process than are available in the standard ASP.NET controls. For example, here is the order in which batch mode event handlers are called for the Infragistics DataGrid (this is an excerpt for documentation I created for an upcoming release of the MM .NET Dev Guide):
>
>

• InitializeLayout - called when the grid is being intialized. Provides a place to initialize grid and column settings
  >
  >
• AddRowBatch - called on post back once for each row that is added to the grid
  >
  >
• UpdateCellBatch - called on post back once for each cell that is updated in the grid, including cells in new and edited rows
  >
  >
• DeleteRowBatch - called on post back once for each row that is deleted in the grid
  >
  >
• Unload - Page-level event called on post back that fires after all updates, deletes, and adds have been applied

>Because I believe this is the best way to go (to use a DataGrid like Infragistics) I have spent many hours integrating this control with MM .NET. What's nice about the MM .NET integration is that it cuts out a tremendous amount of code you would normally have to write using the Infragistics controls because of our use of business objects.
>
>Although it's mechanically possible to do something similar using the standard ASP.NET controls there are so many other issues with these controls that it makes much more sense to leverage MM .NET's data binding with a product like Infragistics where you and your end users will be impressed with the look, feel, and functionality of the controls.
>
>When it comes to non-transactional data binding, retrieving, posting back, and saving as you find in many web applications, the standard MM .NET Web Form controls work great and are used in a good number of web sites with great success...but for this particular problem I think you'll find the solution provided by our subclasses of the Infragistics controls is your best bet.
>
>Regards,