You've brought up a number of the issues I also would like to see addressed in .NET. However, on the databinding, I would like to see VFP take a page from the .NET book... I like being able to bind object properties. It would be super-cool to see Visual FoxPro allow for more than the single ControlSource property or at least be able to define what property the ControlSource effects (other than the Value property for instance). I'm not sure why that has never made it into Visual FoxPro... seems like it is a no-brainer and would make the basecontrols so much more powerful given the datacentric nature of Visual FoxPro. Oh well, I guess it can be done by developers manually in their subclasses somewhat (just not nearly as well as it could be done by the Fox Team in the source).

>Nice! I've been thinking in the opposite direction myself- how to make .NET more FoxPro-like. Some of the coolest things about VFP that .NET doesn't have are:
>
>1) The way in-memory cursors behave almost exactly like tables. You can query your data, come up with an intermediate cursor, use it, possibly index it, create another cursor from scratch, maybe by processing data from a serial port <g>, and then join both of those cursors to your tables with a regular join. Try joining an ADO.NET recordset with a SQL table some time. There are workarounds, but they aren't especially pretty. At the very least, the relevant data from your local cursor should be sent up to the server as an in-memory table and used in the join without having to do all of the coding yourself.
>
>2) The way Fox uses data dynamically - no need to create XML in advance to have a typed data set. When you issue a SELECT or use SQL Passthrough in VFP, the resulting cursor contains columns of typed data. If it's an integer in the source data, it's an integer in your cursor. With ADO.NET, all of the data is boxed into object and you have to unbox it to use it. Sure, it's easier to work with if you create a typed data set, an XML file that describes the data that will fill the DataSet, but if you change your data it breaks. I imagine that generics will eventually make this a little better - at least the columns can be collections of integers instead of objects, but why doesn't the type information come from the server dynamically? Even LINQ seems to use a static object model from the database which will cause your app to break if the data structure is changed- even if the change has nothing to do with the data you're app uses.
>
>3) TableUpdate() and TableRevert(). For some reason, you don't need to use CommandBuilder objects or hand-code insert, update and delete statements for them to work. Duh. And have you seen the gunk that the CommandBuilder objects generate? Why don't DataTables in .NET determining the primary key of the base table dynamically and use it?
>
>4) Don't even get me started on data binding! 1,000,000 thanks to Kevin McNeish for the .NET Mere Mortals Framework. Now if the controls only had input masks based on regular expressions and the whole thing CAME WITH subclasses that you could use instead of having to subclass each thing yourself by hand... Small criticisms really!
>
>5) While I'm at it, why can't you create a single validation object that can be used in the UI, the business object and the back end? Even Fox could use this! Let's face it, it's often desirable to enforce data rules in each of these areas in different situations. There are arguments for each. Wouldn't it be nice to write the validation rule once and use it in any or all of these places? Sometimes this isn't possible. For example, if your rule says that total order amount must be less than $500, you can't enforce that in the UI (unless you go back to the server to add up the orders - probably not what you want to do), but if the rule says that EACH order can be no more than $100, you can put that rule in each of the tiers. The rule should be stored in the back-end (probably), cached in the business object (probably), and passed to the UI to be attached to the form or the bound controls (usually).
>
>EndRant
>
>
>
>What do you think?
>Mike