Hi, Simon,

Basically, you're talking about delayed instantiation, which many people use in VFP (especially with pageframes containing many pages, when running on slow computers).

As far as the binding goes, with .NET, you're not binding to network data, you're binding to ADO.NET data, which by definition is disconnected. So basically you retrieve a record from your back-end database, bring it down to a local ADO.NET data table, bind your controls to the local data, and then run your update process at the end.

(Which, BTW, you can generally do with VFP as well - the VFP controls shouldn't need to bind directly to network data anyway.)

That's not to say that delayed instantiation isn't without merit in .NET. Binding to local data still takes time, painting controls on the screen still takes time, etc. So you may still want to test out performance scenarios and decide if you want to write a little more code to selectively instantiate at run-time.

In .NET, I have cases where I 'drop' a special entry container onto a form, based on run-time condition. I choose to do so because I don't want my form to always have an additional 1-2 second delay everytime the form loads, just for a container that may be used 25% of the time. So again, it's a general consideration.

Hope that helps...

Kevin