xsharp.eu

I have a number of sophisticated (large) VFP applications for the logistics industry. The formidable task of converting has been a deterrent until now. I have been following the X# development on the forum for some time, and am excited to begin testing the conversion now. The VFP-X# Exporter and that is definitely a contributing factor in that respect.

A little background: Our applications are written in VFP and forms are currently bound to VFP Tables. Most clients are running on our Terminal Servers, so performance and reliability have worked ok. Having said that, I would like to move to a SQL back-end, preferable as a second-phase though.

We utilize a number of ActiveX objects, including chilkat and XFRX. Our application is very object-oriented, so forms and controls have many dependencies. Improving UI is one of the main reasons I hope to move away from VFP.

I welcome any recommendations for starting the process. Thanks for all the work you guys have put into this. I'm very excited to jump into this project.

Hello David,

Although I have a VO background and find VO more comfortable than the combination .Net/Visual Studio so I am not in a hurry to migrate, I have one advise which may help you start. I am preparing a migration (for what is probably the inevitable, at some time) with XPorter.

You can start with the VFP Exporter (see https://www.xsharp.eu/forum/public-vfp/ ... rter#16233) and try to reorganize your Foxpro programs to end up with the least amount of conversion errors. If I understand the posting in the mentioned link well, you may be contributing to the quality of the end product of this VFP Exporter as well.

Advantage is that you keep maintaining your VFP projects during converting and also you are improving in the language and environment you are used to. Do this a few times and the actual migration will be a lot easier and less time consuming.

Dick

Hi David,

Hope you will enjoy the journey with X#! A word of warning though first, the system for porting VFP apps to X# is (very heavy!) work in progress, so please do not expect it to be seamless today. X# is already very mature regarding porting applications from Visual Objects, and that's what we plan to achieve for VFP as well, but we are not there yet, this will take more time.

So, for now, I think it's most important to get yourself more familiar with X#, also with the .Net Framework in general (if you are not already familiar with it), write some small test apps using the same code that you would use in VFP in order to see that most of the language is already supported, get familiar with the new environment etc. You can also try porting some parts of your applications, but please do not expect too much already at this point, those things need time!

Hi David,
I'm coming from VO, but nevertheless I would give you some advice: It may be a big advantage that you have your windows built using your own framework classes - that may help in the migration.
But first play a bit with X# and Windows Forms and see what you can achieve on the .NET platform, and what the .NET platform can do for you.
Wolfgang

OASDavid wrote:A little background: Our applications are written in VFP and forms are currently bound to VFP Tables. Most clients are running on our Terminal Servers, so performance and reliability have worked ok. Having said that, I would like to move to a SQL back-end, preferable as a second-phase though.

Given your technical situation I'd first streamline codebase a bit, then move to SQL back end while still in vfp. Accessing SQL backends via cursoradapter, remote view or SQL_Exec() is a particular strength in vfp and tested for ages. No surprizes, get the work done after eliminating a not-optimal parts in advance to save working on them twice or thrice. During that time xSharp will solidify, you have the SQL part already done when porting to a future xSharp, which will have more vfp features implemented and tested. Worst thing IMO would be to to move to SQL backend while porting to xSharp , as small things will crop up in different places between vfp and xSharp. At the moment xSharp is missing quite a few vfp goodies esp. in buffering/tableupdate/cursoradapter area which makes exchanging backends in vfp easier than in most other dev systems - they are planned, but that translates into more work for you until that is finished. Of course, political or budgetary reasons might trump pure "get it done" reasons

regards
thomas