David Simpson
Technical User
thread184-1819416
Hi, my name is David Simpson, I am the developer of FmPro Migrator software you mentioned above.
I appreciate that there are some very good suggestions mentioned by Mike and Chris. I have been a FileMaker Pro developer for 37 years, doing VFP conversions for 13 years and I have been developing FmPro Migrator for 20 years.
I like the idea of porting Visual FoxPro solutions to FileMaker for a few reasons:
1) Just like Visual FoxPro, even large FileMaker Pro solutions can be developed and maintained by a single developer.
2) Claris (used to be named FileMaker Inc.) is a profitable division of a nearly 3T market cap company (Apple).
3) The FileMaker product runs cross-platform on macOS, Windows and IOS. FileMaker Go for IOS is free, so it is easy to deploy a mobile solution. With few exceptions, code you write within FileMaker scripts will run perfectly cross-platform without changes.
There are a few considerations when migrating from Visual FoxPro to FileMaker:
1) FileMaker Pro includes a DBF import feature - however the DBF import doesn't support the reading of Memo fields from DBF files. I have solved that problem with a direct DBF transfer tool.
2) VFP Forms & Reports are directly convertible into FileMaker layouts. The caveat is that most of the time, I am not able to automatically match a field with the underlying DBF field. There are a number of reasons for this situation, though it is trivially easy to fix in FileMaker - just double-click on the field in layout mode, and select the correct table occurrence and field.
3) Table occurrences in FileMaker are similar to views in other databases. When developing with FileMaker, a significant amount of our business logic is built into the relationship graph (similar to using a DBC in Visual FoxPro).
Lets say for instance that you want to show lists of invoices as follows:
Current Invoices
Unpaid Invoices 30 - 60 days
Unpaid Invoices 60 - 90 days
Unpaid Invoices > 90 days
In development environments like Visual FoxPro or LiveCode I would simply write some code to perform a query with the appropriate search criteria, gather the records and populate 4 grids with the results.
Looking at the attached screenshot, you can see that I have created 4 table occurrences in FileMaker to accomplish this task. Then I would create 4 portals on the FileMaker layout to display the data for each of the groups of records.
So doing development in FileMaker does require some re-thinking of the process of creating our business logic to be centered around using the relationship graph.
4) In the past, script conversion has always required a complete rewrite. But with the availability of high quality generative AI models, this task can be made easier. Of course, the process isn't perfect, but it can be a big help to a new developer giving you ideas of which commands are available for a given task. And this technology will only continue to get better in the future.
Here is a sample script I converted with the VFP Code Conversion Workbench:
======== Example: VFP
PROCEDURE KeyPress
LPARAMETERS nKeyCode, nShiftAltCtrl
this.drawmode = 10
ENDPROC
======== Example: FileMaker Pro
// FileMaker Pro
// This code should be placed in a script trigger that runs on a key press event
Set Variable [ $nKeyCode ; Value: Get(TriggerKeystroke) ]
Set Variable [ $nShiftAltCtrl ; Value: Get(TriggerModifierKeys) ]
Set Variable [ $this.drawmode ; Value: 10 ]
===========
The automated conversion isn't 100% perfect, but I am very impressed with the suggestions and the correct syntax which was generated. For instance the Get(TriggerKeystroke) is a really good idea I had not considered until I tested the script. So even for an experienced developer, the machine learning models can provide valuable suggestions.
These converted scripts can now be pasted directly into the FileMaker Script Workspace window, in addition to being saved as text files. When the scripts are pasted into FileMaker, each line consists of a commented line of text. You would then select a new script step from the list of available steps in the right panel. From there you could copy pieces of the automatically converted text to form the new instruction, so that you don't need to retype everything.
Virtual Machines
Also, one of the suggestions was to use a virtual machine to run Visual FoxPro on macOS. I have been running Visual FoxPro on my macOS MacBook Pros for years by using Parallels Desktop. And you will be happy to know that this actually works very well on Apple Silicon CPUs where I have Parallels Desktop running Windows 11 ARM and Visual FoxPro running within the VM. Microsoft's x86 emulation on ARM CPUs seems to work very well, and very fast for this task. And in fact the x86-64bit/x86-32bit versions of FmPro Migrator work flawlessly using Microsoft's emulation on ARM too. I am impressed with the great job Microsoft has done with this feature in terms of compatibility and performance.
David Simpson
Hi, my name is David Simpson, I am the developer of FmPro Migrator software you mentioned above.
I appreciate that there are some very good suggestions mentioned by Mike and Chris. I have been a FileMaker Pro developer for 37 years, doing VFP conversions for 13 years and I have been developing FmPro Migrator for 20 years.
I like the idea of porting Visual FoxPro solutions to FileMaker for a few reasons:
1) Just like Visual FoxPro, even large FileMaker Pro solutions can be developed and maintained by a single developer.
2) Claris (used to be named FileMaker Inc.) is a profitable division of a nearly 3T market cap company (Apple).
3) The FileMaker product runs cross-platform on macOS, Windows and IOS. FileMaker Go for IOS is free, so it is easy to deploy a mobile solution. With few exceptions, code you write within FileMaker scripts will run perfectly cross-platform without changes.
There are a few considerations when migrating from Visual FoxPro to FileMaker:
1) FileMaker Pro includes a DBF import feature - however the DBF import doesn't support the reading of Memo fields from DBF files. I have solved that problem with a direct DBF transfer tool.
2) VFP Forms & Reports are directly convertible into FileMaker layouts. The caveat is that most of the time, I am not able to automatically match a field with the underlying DBF field. There are a number of reasons for this situation, though it is trivially easy to fix in FileMaker - just double-click on the field in layout mode, and select the correct table occurrence and field.
3) Table occurrences in FileMaker are similar to views in other databases. When developing with FileMaker, a significant amount of our business logic is built into the relationship graph (similar to using a DBC in Visual FoxPro).
Lets say for instance that you want to show lists of invoices as follows:
Current Invoices
Unpaid Invoices 30 - 60 days
Unpaid Invoices 60 - 90 days
Unpaid Invoices > 90 days
In development environments like Visual FoxPro or LiveCode I would simply write some code to perform a query with the appropriate search criteria, gather the records and populate 4 grids with the results.
Looking at the attached screenshot, you can see that I have created 4 table occurrences in FileMaker to accomplish this task. Then I would create 4 portals on the FileMaker layout to display the data for each of the groups of records.
So doing development in FileMaker does require some re-thinking of the process of creating our business logic to be centered around using the relationship graph.
4) In the past, script conversion has always required a complete rewrite. But with the availability of high quality generative AI models, this task can be made easier. Of course, the process isn't perfect, but it can be a big help to a new developer giving you ideas of which commands are available for a given task. And this technology will only continue to get better in the future.
Here is a sample script I converted with the VFP Code Conversion Workbench:
======== Example: VFP
PROCEDURE KeyPress
LPARAMETERS nKeyCode, nShiftAltCtrl
this.drawmode = 10
ENDPROC
======== Example: FileMaker Pro
// FileMaker Pro
// This code should be placed in a script trigger that runs on a key press event
Set Variable [ $nKeyCode ; Value: Get(TriggerKeystroke) ]
Set Variable [ $nShiftAltCtrl ; Value: Get(TriggerModifierKeys) ]
Set Variable [ $this.drawmode ; Value: 10 ]
===========
The automated conversion isn't 100% perfect, but I am very impressed with the suggestions and the correct syntax which was generated. For instance the Get(TriggerKeystroke) is a really good idea I had not considered until I tested the script. So even for an experienced developer, the machine learning models can provide valuable suggestions.
These converted scripts can now be pasted directly into the FileMaker Script Workspace window, in addition to being saved as text files. When the scripts are pasted into FileMaker, each line consists of a commented line of text. You would then select a new script step from the list of available steps in the right panel. From there you could copy pieces of the automatically converted text to form the new instruction, so that you don't need to retype everything.
Virtual Machines
Also, one of the suggestions was to use a virtual machine to run Visual FoxPro on macOS. I have been running Visual FoxPro on my macOS MacBook Pros for years by using Parallels Desktop. And you will be happy to know that this actually works very well on Apple Silicon CPUs where I have Parallels Desktop running Windows 11 ARM and Visual FoxPro running within the VM. Microsoft's x86 emulation on ARM CPUs seems to work very well, and very fast for this task. And in fact the x86-64bit/x86-32bit versions of FmPro Migrator work flawlessly using Microsoft's emulation on ARM too. I am impressed with the great job Microsoft has done with this feature in terms of compatibility and performance.
David Simpson
