Based on what I read in Dave's email, what made the short term solution feasible is the fact that the "calculation engine" was encapuslated in a class - capable of being exposed in a COM-Component.

Going further than that - which would involve a total rewrite of the app - you would definitely undertake the process of a functional design. As time goes on, web-based applications are being more and more feasible - and easier to develop.

Server-based/distributed apps is what the state of the art is today - and Fox does not support that paradigm all that well. Elements can play in the sand-box - which is a good thing for short-term/stop-gap measures.

John


><snip>
>
>>It is negligence to the extent that there is a great deal of writing on the wall. As Dave Stephenson pointed out - if you have a short term need to get something on the web, then preserving as much of the Fox Code as possible by way of COM Components is a feasible move - but this is only a short term solution. In other words, it is a stop-gap measure at best. In the intermediate to long term range, firms better be thinking of how to migrate their code to platforms that are more supported and innovated.
>
><snip>
>
>Interesting. So you could take the equivalent of the methods in a form, or the classes in code, or whatever and create individual COM Components and then have the HTML code pass paramenters to and return information from the components? Or did I over-simplify this?