Browse All Articles > My Journey From FoxPro to .NET
The journey from FoxPro to C# started years ago. Specifically, it started in 2009. My work colleague and I had done a lot of research in an attempt to make an informed decision about the legacy code that had evolved since the early days of FoxPro in 1983 to the current Visual FoxPro 9. We heard the news that Microsoft had decided to dead-end support for FoxPro and we both agreed that we had to take steps forward to move to a new programming platform.
At first we were overwhelmed. How could we possibly take on such a large project? We had hundreds of thousands of lines of program code along with over 100 FoxPro free tables. Back when the company was started in 1983, one woman worked alone managing the software needs of a specialty niche known as the reinsurance industry. I then joined her team in 1999; at first part time and then later as a full time programmer. The owner handled the design and I handled the development -- we made a good team. We evolved from FoxPro for DOS, to FoxPro for Windows, to Visual FoxPro 8 and finally Visual FoxPro 9. The needs and requirements of the world-wide client base grew as the capabilities of FoxPro became more modernized.
One decision we made was to solicit the assistance of an established software firm in Ireland, where a large majority of our clients were based. After several visits with the partner software firm, we received the best piece of advice yet. This one piece of advice moved us out of the overwhelmed state into a definitive plan of action, which was to take baby steps.
First, we would move all the FoxPro free tables that were a part of the software package into SQL Server, adapting the FoxPro user interface to work with very convenient FoxPro views for the smaller free tables and to use ODBC connections to extract and update the large transactional tables. It wasn’t a small or easy job, but we were able to spend the next two years upgrading our clients to SQL Server.
In 2011 we began the tedious task of planning out the new user interface in .NET. I was given the choice of a new programming language, since I would be doing the actual development of moving from FoxPro to .NET. I can’t even begin to tell you how many articles and words of advice that I read in an effort to make the best decision. To this day, I don’t regret the choice I made. I decided on C#, which was seemingly light years different than the FoxPro language I had used since 1999. To help my transition from old to new, I worked closely with a mentor from Philadelphia for two different sessions, a few days at a time. This gave me a good kick start and I started moving forward on my own from that point.
It was bewildering at first to understand the very strict environment of C# compared to FoxPro. I’m afraid to say that FoxPro encouraged bad behavior for programmers. I often stumbled over the issue of C# being case sensitive, trying to debug to find why something wasn’t compiling. Properties and variables had to be declared and strictly typed. Parameters couldn’t be loosely used or not used by the calling program (like we could do in FoxPro). In addition, the syntax was confusing at first with the same words meaning different things in the two languages (i.e., public, private, etc.). In C# each line of code was required to have a semi-colon at the end, in FoxPro a semi-colon meant a continuation to the next line. The syntax of the IF, FOR, and CASE statements was different enough to force me to keep stopping to remember what the proper syntax was, especially since I was also creating a lot of stored procedures in SQL Server using entirely different syntax.
In our FoxPro version of the software, there was no layering at all until we moved the data to SQL Server. Even with the SQL version, we only had two layers; the user interface and the data. To further work with the C# language and in an attempt to make sure I was following programming standards, I signed up for online classes diligently worked with the sample code they provided with the course, so I could understand the entire organization of projects and solutions.
I was finally getting comfortable with C# and was able to create a core product that could be the launching pad for the multiple “modules” that our software provided to clients, depending on their needs and licenses. I was pleased with how I had organized everything, with a separate DLL for each module, each business module, and each data access module. We could disburse each DLL (depending on the client) along with our standard core.
At first, the menu was a standard menu bar that was not the end goal that we desired. I tried a variety of different menu presentations that never met with 100% approval. Even with that in mind, I was able to continue on with the inner workings of the core program, knowing that I could use the code regardless of the final decision for the menu presentation.
After some research, I found a third-party product that had some beautiful “Metro” screens. They had the appearance and behavior of Windows 8 screens, with tiles and nice colors. I purchased the product and mocked up a menu screen that was not really usable, but would give my colleague a feel for the menu presentation. She loved it. From that point, I was able to create table driven menu tiles to allow each client to have the maximum flexibility. The same screen is used for every client, but the tiles are completely based on the menu table. Most of our clients have multiple companies within their systems. Our new software even allows a different menu based on the selected company, if so desired.
After the core and menu system was completed, I was able to create many new Windows forms for the option grids to use during period-end processing that is part of the software package. The next phase is to develop the maintenance screens and reporting option grids.
It has been a secret pleasure to see what comes out of starting over. Designs and interfaces that we wished we had done differently are now possible with a “new” system. Our software has always used a rule file to determine starting values on some of the option grids, names to show on screen labels for certain fields, etc. I was able to completely empty out the bloated rule table and start putting each rule back in, one at a time, as they were needed and used during the development of the various screens.
It has been a long journey and there is still more to come. But, it is also a very rewarding transition that I don’t regret for even one second. I can tell you right now, I could never had completed what I have done so far without being able to search online for code samples and answers to questions I have had during the development of the .NET version of our software. Sites like Experts Exchange have a community of programmers who are willing and able to assist new developers through the pitfalls of developing software that is compliant with the standards set by the .NET community. I have also found that I am not alone in the fact that I am moving from FoxPro to .NET. Those particular comrades know how it feels to move from a data-concentric programming language to a platform like C#. I have to thank all of the very clever and generous programmers who have provided tips to help me through my journey.
At first we were overwhelmed. How could we possibly take on such a large project? We had hundreds of thousands of lines of program code along with over 100 FoxPro free tables. Back when the company was started in 1983, one woman worked alone managing the software needs of a specialty niche known as the reinsurance industry. I then joined her team in 1999; at first part time and then later as a full time programmer. The owner handled the design and I handled the development -- we made a good team. We evolved from FoxPro for DOS, to FoxPro for Windows, to Visual FoxPro 8 and finally Visual FoxPro 9. The needs and requirements of the world-wide client base grew as the capabilities of FoxPro became more modernized.
One decision we made was to solicit the assistance of an established software firm in Ireland, where a large majority of our clients were based. After several visits with the partner software firm, we received the best piece of advice yet. This one piece of advice moved us out of the overwhelmed state into a definitive plan of action, which was to take baby steps.
First, we would move all the FoxPro free tables that were a part of the software package into SQL Server, adapting the FoxPro user interface to work with very convenient FoxPro views for the smaller free tables and to use ODBC connections to extract and update the large transactional tables. It wasn’t a small or easy job, but we were able to spend the next two years upgrading our clients to SQL Server.
In 2011 we began the tedious task of planning out the new user interface in .NET. I was given the choice of a new programming language, since I would be doing the actual development of moving from FoxPro to .NET. I can’t even begin to tell you how many articles and words of advice that I read in an effort to make the best decision. To this day, I don’t regret the choice I made. I decided on C#, which was seemingly light years different than the FoxPro language I had used since 1999. To help my transition from old to new, I worked closely with a mentor from Philadelphia for two different sessions, a few days at a time. This gave me a good kick start and I started moving forward on my own from that point.
It was bewildering at first to understand the very strict environment of C# compared to FoxPro. I’m afraid to say that FoxPro encouraged bad behavior for programmers. I often stumbled over the issue of C# being case sensitive, trying to debug to find why something wasn’t compiling. Properties and variables had to be declared and strictly typed. Parameters couldn’t be loosely used or not used by the calling program (like we could do in FoxPro). In addition, the syntax was confusing at first with the same words meaning different things in the two languages (i.e., public, private, etc.). In C# each line of code was required to have a semi-colon at the end, in FoxPro a semi-colon meant a continuation to the next line. The syntax of the IF, FOR, and CASE statements was different enough to force me to keep stopping to remember what the proper syntax was, especially since I was also creating a lot of stored procedures in SQL Server using entirely different syntax.
In our FoxPro version of the software, there was no layering at all until we moved the data to SQL Server. Even with the SQL version, we only had two layers; the user interface and the data. To further work with the C# language and in an attempt to make sure I was following programming standards, I signed up for online classes diligently worked with the sample code they provided with the course, so I could understand the entire organization of projects and solutions.
I was finally getting comfortable with C# and was able to create a core product that could be the launching pad for the multiple “modules” that our software provided to clients, depending on their needs and licenses. I was pleased with how I had organized everything, with a separate DLL for each module, each business module, and each data access module. We could disburse each DLL (depending on the client) along with our standard core.
At first, the menu was a standard menu bar that was not the end goal that we desired. I tried a variety of different menu presentations that never met with 100% approval. Even with that in mind, I was able to continue on with the inner workings of the core program, knowing that I could use the code regardless of the final decision for the menu presentation.
After some research, I found a third-party product that had some beautiful “Metro” screens. They had the appearance and behavior of Windows 8 screens, with tiles and nice colors. I purchased the product and mocked up a menu screen that was not really usable, but would give my colleague a feel for the menu presentation. She loved it. From that point, I was able to create table driven menu tiles to allow each client to have the maximum flexibility. The same screen is used for every client, but the tiles are completely based on the menu table. Most of our clients have multiple companies within their systems. Our new software even allows a different menu based on the selected company, if so desired.
After the core and menu system was completed, I was able to create many new Windows forms for the option grids to use during period-end processing that is part of the software package. The next phase is to develop the maintenance screens and reporting option grids.
It has been a secret pleasure to see what comes out of starting over. Designs and interfaces that we wished we had done differently are now possible with a “new” system. Our software has always used a rule file to determine starting values on some of the option grids, names to show on screen labels for certain fields, etc. I was able to completely empty out the bloated rule table and start putting each rule back in, one at a time, as they were needed and used during the development of the various screens.
It has been a long journey and there is still more to come. But, it is also a very rewarding transition that I don’t regret for even one second. I can tell you right now, I could never had completed what I have done so far without being able to search online for code samples and answers to questions I have had during the development of the .NET version of our software. Sites like Experts Exchange have a community of programmers who are willing and able to assist new developers through the pitfalls of developing software that is compliant with the standards set by the .NET community. I have also found that I am not alone in the fact that I am moving from FoxPro to .NET. Those particular comrades know how it feels to move from a data-concentric programming language to a platform like C#. I have to thank all of the very clever and generous programmers who have provided tips to help me through my journey.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)