Hi Terry,
Terry wrote:I agree with all you've said.
BUT I think you are arguing from a purely technical perspective.
All you've suggested may appear straight forward, it's good advice but I'll guarantee it won't be so easy in practice; implementation will take time and human resources.
The development team must take into account the need to generate revenue. Failure to address customers current requirements would compromise that.
Ok, I'll try to rephrase my argument from the economic side of/for xSharp developers. As far as I have grokked history of xSharp is tied to VO and Vulcan users which received no or unsatisfying bugfixes and were given no perspective. Seems to be also worry that in the future some previously used runtime would cease to work - unclear if this is connected to previous runtime being 32-bit (wich might be dropped when 128bit OS with 64 subsystem arrives) or other reasons. Developers were already working on previous runtime and used smart in-between-step of using VO dlls. Customers the group already using VO and closer cousins than vfp. Makes total sense if your company is built on software grown over many years. VO compstibility extremely high as those already bought dlls were reused.
Vfp in its heyday probably had larger # of devs and apps, but many moved themselves and their apps since 2007. Most very large apps are already ported. Those that did not move have stable systems, where faster CPU and SSD fixed problems of growing data sizes. They can build web apps if needed, with moderate server running the form and AJAX-updating client side HTML. Communicating with current "evolved" services PITA, but you can COM into Java, Dotnet or host Dotnet runtime if you wish to avoid low level picking apart ever-more automated XML and similar stuff. Not pretty, but doable. Backend via C/S already the stength of vfp, if backend uses SQL.
What does xSharp offer those remainers ? Another desktop with better Winform/GUI integration. Certainly, but those needeing eye candy already bought activX or Dotnet controls and integrated them.
Web: already doable or done, via FoxIncloud or COM called by server, either via West-Wind or AS#p.Net. No pressing problem - FoxInCloud can port even to mobile with a GUI-refit (not total rewrite), but is server based like old ASP or Java Vaadin solutions - no way to run offline. Possible to run on Linux if one is not afraid of MS litigation, but not really needed as Win is standard desktop OS for most users.
As I am a hired gun programmer, not tending own solution - when could I honestly say the effort of porting to xSharp is worth it if one of my previous customers asks me about it? And there will be some effort,
I stayed in vfp for several reasons: long term contract consolidating/datamining big iron data, a few data upsizes to various backends,sometimes asking for ingenious ways to keep most of existing code while rearchitechting to eliminate most perceived warts - and the personal preference for vfp cursors as cached/mirrored remote used data in MVVM pattern without ORM twistings, which I think already sport most of the benefits Flux (re-)introduced to web programming: Single Source of Truth, redundance-free normalized data store and has benefit of SQL over it and backend. Have done other languages when starting years ago and did a few more last decade...
This pattern I like - found in cursoradapter, conflict managment and buffering I believe will benefit current users VO, as I think backend handling of vfp is superior, but those who already are customers could do half of that out of the box via ADO.Net if they really want to and redesign their apps a bit.
Only thing
really missing for vfpers is ARM/mobile app to install, PWA-web client able to work offline (doable via WASM later) and IoT starting from Raspberry down. If customer needs that or future new stuff - he needs DotNet with xSharp, but more current versions like Core 3 upward. For most others, maintaining current vfp is good enough. With less fear of "stick of failing runtime", you need high compatibility AND carrot of more than WinForms. So designing GUI for other options right from the start IMO is biz sense and avoids double effort. Similar to putting correct wheels on your car depending on destination, for ex. before driving into ski area in winter, tooling up to Core might be beneficial
Adding vfp highlights/"can't do without its" first would be adding to "worth" of xSharp to build solutions (and is aligned with my personal bias, so weigh with care) as it might add options for VO to upsize to C/S with another/better pattern, so biz benefit even if few vfp'ers jump aboard.
I hope to sneak my favorite state managment into code perhaps done in C# or do ports where it makes sense and.I am sorry that so few vfp coders are interested/helping currently, but xSharp is far from usable to replace vfp apps in current state for those up to their ears in maintainance. Just having xSharp as another option is not enough to get them into FOX, they need new biz benefit.
I personally want to have an alternative middle layer if asked to do Dotnet (and be up-to-date there again), perhaps (help) redesign vfp apps to mobile and better web, but uncertain if I can really use it in the future, so I am only helping a bit and learning - with resolve to get into FOX for a few years via percentage from gigs if they materialze, otherwise it is just a mixture of hobby, mental gymnastics coupled with learning and (perhaps) pipe dream
still mostly tech based, but biz motives intertwined
my 0.02€
thomas