In 1988, I started working on an inventory tracking application for an equipment rental company, using dBaseIII+. It began as a part-time hobby, but the user base grew to 20+ businesses, so I couldn't stop. The application managed inventory, orders, quotations, customers, bookings, equipment delivery, and invoicing.
Over the years, I migrated the application from dBaseIII+ to Clipper summer '87 to 5.1/5.2. The transition to DBFCDX from DBFNTX was significant, but painless. In 1998/1999, I moved to the CAVO 2.5 Windows environment, which had a steep learning curve since everything was event-driven.
I used third-party libraries like Fab Tools, bBrowser, and ReportPro, which provided excellent capabilities, but linking external libraries was a challenge which I partially solved by allowing undeclared VARs. Unfortunately, in 2005, I turned off the "undeclared vars" compiler warning for good. By the time VO2.8 was available, I was unable to migrate to it due to the numerous undeclared VARs and other errors I had inadvertently created. I gave up trying to migrate from 2.7b to 2.8, and for the next ten years, the application continued to grow in 2.7b. The occurrence of 5333 errors, undocumented features, and untraceable bugs increased, but it remained a usable application.
The converted application currently consists of over 212,000 (non-empty) lines in 75 program modules, 17,000 entities, and 8,571,762 characters, so there was plenty of room to hide bugs.
In September 2019, I discovered X# and contacted Chris Pyrgas of the development team, who offered to review and test my AEF to provide advice on the pathway to migration. The X# development team was kind in their feedback, although they were likely horrified by what they found. They said it was "useful" and "beneficial" since it allowed them to "extend" the VOXporter and highlighted some macro compiler improvements needed to cope with 35 years' worth of questionable programming. Robert, Nikos, and Chris's expertise, dedication, and other contributions behind the scenes were crucial to the success of the result.
Unfortunately, in 2019, the "third-party tools" were not quite ready, and my VO application required a significant amount of tidying up. Then COVID-19 hit, and mental pressures and business stress consumed all my attention. I returned to the comfort of adding more and more undeclared variables to the VO2.7b application.
In August 2022, I decided to try again. I had discovered an interesting case study on the X# website by Peter Monadjemi from EurekaFach. After reading that and a few others, I became hopeful that it might be possible to migrate my application. I contacted Chris again. It also transpired that Fabrice (Fab Tools) and Joachim (bBrowser) had recently provided X# updates for their products, so everything was now in order.
To demonstrate that it would indeed be possible, they took my AEF and deleted 95% of the PRG files to provide a "quick and dirty" glimpse of my application running in X#. It was only the front screen and some menus, but it was the inspiration I needed.
With a fresh export, there were over 6,000 errors and 14,000 warnings, but luckily many of these were about similar things. With Chris's guidance, we identified each problem and the corrective action required, and I went off and implemented the necessary changes. We worked through them one problem at a time, and after only eight weeks (part-time), the migration was complete.
The most surprising aspect to me was that the X# compiler found 40+ serious errors in my VO code that the VO compiler had missed. These included typos and spelling mistakes, unfinished lines, faulty logic, and "features" that never worked properly in the VO2.7b application but compiled and ran.
For the first six weeks of the process, I also applied the corrections to the original VO program and fixed the undeclared VARs and other errors. Then I would do a fresh VOXport to start again in X#. Through repeating this process and correcting the VO version as I went, I ended up with a very stable and fast "final version" of the VO2.4b application.
Through the migration process, I also got to see how much more pleasant it was to develop in X# compared to VO. The tools and features available in X# really put the fun back into programming, and the XIDE is more user-friendly and capable than the VO IDE. The learning curve may have been steep, but it was quite short and worth it. While I did briefly try the VS environment, I elected to continue with the XIDE, as it was already somewhat familiar to me and I had already started there.
Converting to .Net opens many doors to integrating third-party controls, WinForms, and creating other features that were not possible in VO.
There are literally millions of .Net controls that you can add to your applications. Graphics and CAD, animation, gauges. The first I have added is a scheduling control, purchased from DevExpress, which provides an object similar to Outlook calendar that can be programmed with any possibilities.
The X# development team is responsive and always professional. The help and assistance from the wider community is priceless and generous, and you'll get the answers you need to boost your project.
Bringing an older VO application to a .Net environment may seem daunting at first, but I've found it a worthwhile investment. The benefits of using modern tools and features are significant, and the migration process will help you identify and fix issues in your code that may have otherwise gone unnoticed for years.
If you're on the fence about making the switch, I highly recommend trying the VOXporter and exploring X#. You may be surprised at how much more efficient your coding can be in this environment. Even if you aren't quite ready to take the step to X#, I'd still recommend trying the VOXporter and be surprisedat what the X# compiler finds wrong in your code.
Some screenshots from the converted application:
