>There are lots of options out there for new development. Personally I've chosen the .NET path originally because it was the closest thing to Fox and offered both Web and Windows development at the time. Now .NET is also cross platform and has tooling for most platforms including mobile (using Xamarin). It works very well on the Web, on desktop (Windows) and has options for creating mobile apps via Xamarin.

Full ACK

>
>One of the main reason I've stuck with .NET over the years is that it's the most widely used platform for Windows desktop apps today of which I still have a need for both for myself (tools mostly) and also for a number of clients. There aren't many options for desktop apps anymore as vendors seem to have lost interest in OS platforms in general (both Microsoft and Apple haven't done squat to their languishing OS offerings). One other popular option today is Electron which is basically Web based UIs that run on the desktop but that brings a whole other set of issues (like having to build out most of your desktop UI through clumsy Web interfaces).

If the task were creating a totally new app, Electron would probably first thing I'd reccommend to check. But as this is a port on a local LAN, users are probably accustomed to minimal protocol overhead incurred between data store and client machine. Electron apps often include web-typical ORM layers plus protocol "conversions" (is JSON a conversion for Javascript ?), which do typically not matter when accessing via internet, as internet latency is greater than protocol overhead. Even with Javascript JIT code/function call speed running circles around poor old vfp p-code interpreter speeds, complexity of ORM layers plus transfer protocol might make ported app slower than old app if sizeable data is moved between client and remote data store. Such a result would not be allowed in a port - in a new app, fine tuning would be scheduled, whereas a port would be ridiculed and scuttled ;-)

>
>I've seen a lot of people transition from FoxPro to .NET and work with quite a few clients that have made that switch. Some have done really well and really embraced the changes and for those people there's no going back. Others have not fared so well. How well that goes mostly is about attitude. If people move and expect .NET to behave like FoxPro things are going to be difficult. A lot also depends on how you built FoxPro applications. It has always been possible to build FoxPro applications in well organized way using Business Objects and proper separation of concerns that is much closer on what you pretty much have to do on other platforms. if that's the way you already work, transitioning to other technologies will also be much easier.

Full ACK again. I ALWAYS argue for a pure maintainance architecture rewrite in vfp using same tests as before to create a clean and layered source to start porting from. Replacing layers stepwise over time during a few release circles can be cheaper by a magnitude - including the maintainance effort for the "unneccessary" rewrite/rearchitecture of the to-be-abandoned fox code.

Keeps feature creep at bay, commitee meeting time down, needs only small enhancement of dev crew, allows development following a mostly single source tree with branches always close to trunk ;-)


>
>Switching to any language other than xBase will be a learning curve, but again I think the biggest hurdle to success is clinging to old ways of doing things and expecting things to work the same way. With an open mind to different approaches any new platform can be adapted successfully.

Yupp. Still, there are some principles a good coder should have: DRY, YAGNI, (chunky, not chatty), KISS and so on ;-)

regards

thomas