Mike,

>I have given up on the idea of calling into VFP form methods. You have convinced me that won't work. But there is a lot of VFP code in the existing app that can be reused, with tweaking. The part that scared me most about the design / approach that was handed down to me was the interop between FoxPro code and a web front end. Doesn't WebConnection handle that? I do not need to use .NET WinForms per se. I just need a web front end that reuses as much algorithmic logic, which is FoxPro code, as possible.

That's the best way to approach it -- looking for the sections of logic in your existing app that would be difficult or time-consuming to rewrite and bundling them up into methods of classes that can be made OLEPUBLIC. Then, you can build them as COM MTDLLs, put them into Component Services (COM+) and call them easily from ASP.NET web pages.

I have done just that on a project for an insurance broker, where they had a very intensive rate comparison engine that had been fine-tuned and honed over the years. We put a front-end interface on it that received incoming parameters (actually an XML representation of a table with rate comparison criteria requests) and wrapped the old Fox 2.6 code, returning a result back in XML.

The ASP.NET web page created the XML request, made the call to the VFP COM object, received the XML back, read it into a .NET dataset, and bound it to a grid (just a couple of lines of code to handle the result). It was very fast and very easy to use, once configured.

Alternatively, you could use Web Connection as the web front-end and have it directly call your Fox class methods instead of going through the COM layer. The advantage here might be caching some of that SQL Server data you referred to in cursors in the Web Connection server instance instead of having to query it from SQL Server on every hit -- if your app specs would allow using cached data.

Bottom line: Close interaction with lots of back-and-forth between a .NET app's user interface and calls to VFP code is probably not as feasible as a .NET user interface that makes a wisely-structured call to VFP for essential logic at key points in the app. Trying to make VFP respond in an extremely interactive way with everything that happens in the .NET UI is probably wishful thinking. Web Connection allows closer interaction with VFP code, but any Web interface is not going to be as responsive as a desktop app. But, you know your app better than Rick or I. :-)