>Hi Mike,
>
>>All right, all right, I accept that the approach my boss wants is probably not going to work.
>
>I'm not trying to sway you <g>. Go ahead and try. I don't know your app - maybe it's a clean app that has UI and business logic separated out at the form level - who knows. But in my experience, although it might seem easier to try and reuse the existing screen code, it almost certainly won't be in the long run.
>
>>This may sound like a setup but is Web Connection something we should consider for this job? The ability to interface between a web form and VFP code is built in, so having to build COM interfaces or whatever is one major headache I think WC would allow me to avoid. Our existing code is full of references to VFP memvars (some set earlier in the app) and form PEMs, all of which would have to be rewritten, but it might give me a leg up. I don't need a PhD in corporate politics to know they do NOT want to throw away or redesign the existing VFP code. The timeframe is too short.
>
>I'm not sure I understand the connection between your original idea of running a .NET Winforms app and hooking the Fox code to it and Web Connection which is a Web environment. Web Connection does let you work with Fox code natively all the way through without COM or .NET code, but the issue of trying to call into Forms still would exist. This mitigates the potential for COM interop issues (of which there are many) but it still leaves the main architectual issue.


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.

Mike