This does not mean it would take twice as long or twice the cost to do it in .NET. When you get "excellent reputations", you tend to charge more. It's quite possible that it could have been done in .NET for the price you quoted.


>You are quite mistaken about FoxInCloud. It does not make a VFP app "appear to the user via their browser." It adapts a VFP app and creates actual HTML/JS/CSS, just as if you had done it yourself with HTML, jQuery, etc. You then have an HTML/jQuery app which you can run as is or add anything you might normally add to an HTML/jQuery application.
>
>And the app still runs fine as a VFP app.
>
>At the risk of beating an old and dead horse, people here who claim that the great tools of .Net etc. enable them to do all kinds of things they could never do in VFP and do them faster most likely never did much with VFP. (There are some here I grant expert in both, such as Rick Strahl.)
>
>Let's take an example. I just had a client who had a very very old DOS app that needed to be replaced to enable them to take advantage of modern and Internet related technologies. I would not really consider it a conversion, as the app was 25 years old and the requirements have changed dramatically, so I would consider the DOS app more of a guideline in developing the specs.
>
>The company received three .Net proposals from companies with excellent reputations. I told them it could be done as a 100% HTML/Jquery/CSS app for approximately 50% of what they were being quoted - both 50% less in time and costs - by developing from scratch in VFP with FoxInCloud.
>
>They were skeptical to say the least, but I convinced them. Then it got better. As they started deploying the app, they realized that the first sites that needed it were in outlying areas and had significant issues maintaining a decent speed Internet connection. They developed a solution for that, but it could take up to 2 years. So I just saved the day by letting them run the exact same HTML/jQuery app in VFP as a remoteapp. Once codebase, one project. If you had any understanding of what FoxInCloud can do, you would be falling out of your chair in awe.
>
>The app has a myriad of special features, connects to numerous external devices, has many custom JS, etc. In VFP those devices are accessed by ActiveX controls and in HTML via Javascript routines.
>
>Tne bottom line is that as a consultant I have one and only one goal, and it should never change a bit: give the client what they need in the most efficient manner. Ooooh, I'm good at .Net. Ooooh, I learned to be a wiz in Java. Ooohh I am a wiz in good olde VFP -- none of that is relevant in the least unless you are making a commercial app you plan to sell, in which case do as you please.
>
>And a company that pays to have a VFP app converted to something else? There could be a reason, but most likely it is negligence or ignorance on the part of the company and the developers. I have only ever seen one VFP conversion to another platform that had a legitimate business reason - and business reasons are the ONLY acceptable reasons. It must make or save money, short or long term, to merit consideration.
>
>Ignorance is no excuse. My responsibility is to the client. I have sent clients elsewhere if I thought it would better serve them. For the record, we have a very good .Net guy and if a client insists on not listening to our suggestions we will give them whatever platform they want. If something better than VFP with FoxInCloud came along tomorrow, I would grab it, But it has been years and nothing is close.