Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

Today I extended a class based file conversion tool. I have different text files and need to be able to import a particular text file and export it into a new format, basically doing different transformations to the line items.

I did some work in the past on this for the same customer and today they asked for a new file format conversion.

The work to do this was pretty painless. The work was all in writing the code to translate the data.

Here is the structure of my classes and what they do:

  1. First there is a simple form with two buttons. One to select the file to translate, and after it is selected and validated, another button to do the translation and specify the location to save the new file. This form instantiates the importFile class.
  2. ImportFile detects the file type by creating a CustomerFile object for each type of customer and running the FindIndentifier method of each CustomerFile object.
  3. CustomerFile is an interface, in VBA that’s an empty class that defines the structure of any class based on it. It requires the class implementing the interface to have certain functions such as ProcessLine.
  4. All of the logic for specifying and reading the file, then outputting the final product is all based in the ImportFile class.
  5. All of the logic to translate a certain customer’s file is in it’s own module named after the customer and implementing the CustomerFile interface. This allows me to use polymorphism in the ImportFile class. It just has to have a generic object specified as a CustomerFile. Then I can assign any of my customer objects to that generic object variable and voila! No new code needs to be written except for a new module based on CustomerFile whenever a new translation is needed.

Almost the entire coding I did was in the new module. There was one other change I had to make to add the new module to the file detection routine in the ImportFile object.