>Bill,
>
>Good to see you here!
>

Thanks Kevin! Hope all is well with you and yours!

>First of all, are you using Beta 10? I've made some significant changes in Web Forms and data binding in this version.

Yes I am. I uninstalled Beta 9, deleted the folders, restarted, and installed Beta 10 the day I got the email.

>In beta 10, if a control's BindingType is set to OneWay or TwoWay it should bind whenever you retrieve data in the BindingSource business object...regardless of the value of IsPostBack.

I could be wrong here...
In mmTextBox.StateChangeHandler code reads:

case (mmBusinessState.Bind):
this.OnBindData(bizObj, e, this.IsPostBack);

then in mmTextBox.OnBindData code reads:

public virtual void OnBindData(mmBusinessObject bindingSource, mmBusinessStateChangeEventArgs e, bool bindBack)

so IsPostBack winds up in bindBack then:

mmWebBindingStrategySimple.BindData(this, bindingSource, bindBack, e);

then in mmBindingStrategy.BindData code reads:
if (bindBack)
{
mmControl.BindBack(dv, MemberName);
}
else
{
mmControl.BindControlToData(dv, MemberName);
}

So if posting back, it doesn't appear BindControlToData gets called. The controls aren't being rebound when I ask the bizobj for a new dataset. I need to spend some more time looking at the events and delegates. Heck, this might not even be the right code.

>The example presents a simple way of persisting data. You're right that persisting to the session object could be a problem if the user sits on their hands and the session expires. With ASP.NET saving the session is a much more viable option than in ASP since you can specify that session state is stored in other places such as SQL Server. Given this option you could further extend the session length knowing that it's persisted in the database. Alternately, you can simply choose to persist the DataSet in SQL Server manually. Long story short, you can choose to persist and retrieve the DataSet any way you like.

Understood. I was hoping for a suggestion. I'm not only concerned with expiration, but having 2 browsers open editing the same table to copy/paste, etc. If it's stored on anything that references only the session it won't work. Almost need to generate a unique id, store it in a hidden field, and use it to reference the proper instance of the dataset. Maybe give up the whole DiffGram concept and use the suggestion of retrieving a new dataset and updating. Possibly storing a record version or timestamp in a hidden field and comparing it inside a transaction during the update to be sure of no concurrency violations.

Any ideas are appreciated.

>
>>3. It appears we are retrieving the schema information in the dataset by default. Could we use that information to set the MaxLength property in the mmTextBox during binding? I wrote a framework for Windows forms in .NET and this feature is extremely helpful.
>
>Funny you should ask...this is in the works for the next beta.
>
>Regards,

Great!