Kevin,

>Guys who take very simple applications and succesfully move them to .NET and taking that as a measure that every VFP application can be succesfully moved to .NET is misleading.

>I'll give you a response later, as I've spent more time on the topic than I care to.

Then stop posting about the issue. It is you who restarted this again, not me.

>But I will say this...these types of presumptuous statements are at the root of the issue - in this case, the belief that the converted apps were 'simple'. I'll ask that you qualify...what 'guys', what 'apps', and why specifically do you consider them 'simple'?

It is a general statement about drawing conclusions on personal experience. As with a awfull lot of issues, it is very dangerous to project your personal experience on all possible solutions. You simply cannot! In order to be able to that, you must have personal experience in converting all kinds of VFP applications into .NET. In practise this is not possible.

The only way you can do this is by looking at a tools' characteristics, its strengts and weaknesses. I know some guys personally who have dissapointing experiences with porting VFP applications to .NET as well as I know some members up here who are not that impressed as you seem to be. Are those personal experiences an objective measure on its own? Of course not. And arguing on this level is not going to be constructive ever because:

- People who have succeeded in porting simple apps are going to project this on all apps.
- People with negative experience might not have had the right knowledge to do this.
- People with negative experience might had to deal with issues that were so easy to solve in VFP but a hell lot more difficult or time consuming in .NET

No, way better is then, again, to look at a tools' characteristics and determine its strengths and weaknesses and draw your conclusions from there. It makes no sence to write a complex database application in Assembly or C/C++, nor does it make sense to try to develop a device driver in VFP. It also does not make sense to mimic a SAP, BAAN or NAVISION ERP/ERM solution in plain .NET.

Walter,