Aldridge Software Limited
  Home     HTML     AJAX     PHP   FoxPro   CSS     MySql  
"To a man with a hammer, everything looks like a nail" - with FoxPro, you can do anything you want on a PC.
 
I was sitting in the garden of the Old Granary, overlooking the river Frome in Wareham, with my wife and youngest daughter, watching some schoolchildren building rafts out of plastic drums, when it occurred to me that neither the teachers nor the pupils understood the full meaning behind the lesson. The meaning they should have been taught is that very few things in life are permanent. They would successfully build a raft, cross the river and back, but then have to take it apart to get it back to school. Unless you are lucky enough to build the Severn rail crossing, or the Forth road bridge, pretty much everything you do will soon come to waste. The children should have been taught to have fun with the challenge, achieving the goal of crossing the river was of limited value.
 
So it is with software, here I detail 3 of the best programs I have written, taking years to achieve satisfaction with them, only for them to fall into disuse when the companies went bust or were taken over. Writing database programmes is one-step further into the ether than spread sheets. In a spread sheet you can see everything, but people could write their own macros which were a nightmare to debug. In a database programme, you have to believe your data is somewhere, you can't see it all at once, and you are just relying on the vagaries of the operating system to hold it all together. Having said that, FoxPro has rarely lost an index for a table, which can be rebuilt easily, where my experience of Access is that it losses track of tables, index files, etc all the time, so much they even put a 'Repair Database' button on the toolbar in early versions.
 
The programmes are listed in order of most fun to write, useful for the users, and cleverness.
 
1) Powder Coating Formulation: Betta Surface Coatings, turnover: £1m, programmers: 1.
 
Written initially in Dbase II on an Amstrad PCW machine (wow, two tables open at once and 32, yes, count them, 32, memory variables, this was the bees knees at the time), then transferred onto FoxPro 2 on a PC (whey hey, 32 tables open at once, and 256 memory variables, life was getting easier) when Bill Gates finally won the OS wars of the time.
 
Someone once said the best programmes are written by a team of one, and it's downhill from there. This was certainly the case at Betta, I was the only programmer, and the programmes were very stable (no odd changes to tables because someone else wrote a new routine etc.). In its final form, you could show the computer a sample of the colour you wanted, choose whether it was for internal or external use, and whether it was glossy or mat, and the programme would print out a formulation, for any quantity, for production on the shop floor. FoxPro interfaced with a spectrophotometer to read the colour of the sample, and then calculated which pigments would produce the colour, how much of the pigment in total was required to give good opacity (covering), and the resin to give the desired finish.
 
Some of the ideas were based on comments from other chemists (i.e. if you did it in some other way than currently, life would be better, and I was in a position to try these out), such as the idea to base a formulation on 100 parts of resin, and then add pigments to this (giving a random number for the total) where most methods at that time were to base the formulation to come to 100% (or sometimes 102% to allow for production loss). The advantages of this method were many, you could check the ration of resin and hardener (some were 50/50, others 70/30 or 93/7, as long as it added up to 100 you knew it was correct), and you could calculate the minimum pigment (and therefore the maximum filler) for any colour. Our machine couldn't produce a batch size smaller than 1kg, so I based our formulas on 1000. For example, if you needed 400 parts per 1000 of white pigment to give good opacity, but only 40 parts of black pigment per 1000, and you were making a grey with 200 parts of white, you would need 20 parts of black to achieve the opacity, leaving you room for 180 parts of (cheap) filler, thus giving the cheapest formula overall. This is very easy to do based on 1000 parts of resin, but much more difficult if the formula is based on 100%, as you would need to calculate the ratios of resin and pigment on a moving target, which was quite difficult in the days of pocket calculators, with the result that most chemists erred on the side of caution and would use more pigment than necessary.
 
The system was so good that we sold it to overseas companies that wanted to start manufacturing Powder Coatings, but now there are only a few screen shots left.
 
2) Production scheduling: Coopers Furniture, turnover: £5m, programmers: 2.
 
By now, everyone had a PC, Windows 98 was out and we were in Visual FoxPro 5 land. The company were using Paradox on DOS at the time, but were fairly happy to move onto a Windows based system.
 
The best software I wrote for them was a production scheduling systems for the cutting and shaping of wood to make furniture. A wardrobe may consist of (say) 15 different pieces of wood, each requiring different machines and processes before assembly. The programme would take a few parameters, the number of people, the available machines, and the required production for the week, and calculate the best use of the people to show if you required more people on some machines than others to get the work completed on time. Some machines required 2 operators whilst others required only 1, and getting the best route for the components to travel around the machines was essential to keep everyone busy. The time taken for every process for each part of all the furniture was known, so the results were fairly accurate, even allowing for the time to move the components between the machines.
 
Couldn't take a copy of the software, the only thing I have is a print of the final result.
 
3) Accounts etc: Mills Electrical & Mechanical, turnover: £100m, programmers: 2.
 
When I joined, the main accounts were still in FoxPro 2.6 for Windows, run from a server, whilst the rest of the world was on Visual FoxPro 7.
 
I showed them how to run the 2.6 programmes inside the VFP7 shell, and how to run the executable in each PC, so the software could be updated without kicking everyone off the system. The executable grew from 1mb to 7mb with all the new additions that VFP7 could bring, integration with outlook so you could send emails, and my particular favourite, integration with Excel. This was pretty cool, you could create an Excel spread sheet in FoxPro as an object and use IntelliSense (where all the possible methods and properties of an object would be shown when you typed the commands into the command window) to manipulate the individual cells, adding formulas and formatting as you went. This was a rather popular addition to the system.
 
I also came across the wonders of the British tax system (PAYE, CIS), designed in exactly the same way a camel is a horse designed by a committee.
 
With VFP7 came PageFrames (I like these a lot, you get all the information about something all in one page), and FormSets. Although I've seen it written that some programmers don't like FormSets, I found them very useful and intuitive to work with. The only thing we didn't bother using was the DataBase Container, preferring to keep all our tables separate. As the internet was now commonplace, and users wanted to work outside the office, we utilised the ODBC connector to access MySQL tables from remote locations. This was a bit like going back to square one, having to write the SQL as a string then send it to the server, whereas FoxPro had a built in, mighty fast database and the queries can be run from a command line. I think this is one of the reasons Microsoft bought and then controlled (and didn't market) FoxPro. You could type a line of code: browse for customer="C", and instantly get a list of all the customers beginning with "C", no need to create query strings and then execute them. This is about a thousand times better than Access, and in terms of intuition, a million times better than SQL server.
 

Enjoy the journey, we don't serve after-life mints.
 
Contact: noreply at AldridgeSoftware dot co dot uk