File wars - XML v TXT v Registry

I'm afraid that this is going to be a bit of a geeky posting (you mean the others aren't?) and it's going to concern the advantages of using xml files over text files, but it's interesting, so read on.
Most serious programs need to save data in one form or another and there are lots of ways to accomplish this.
I'm going to divide this data into three types - 1 - Program preferences, 2 - Temporary data created by one part of the program and used by another part, 3 - Data records (ie. relational database)

For number 3 the answer is (relatively) straightforward - use a DBMS (database management system) such SQL Server, MySQL, MS Jet (as used by the Wessex Programs) or similar. All the complex database work is taken care of and there is a wealth of documentation to fall back on. (This may be the subject of a future posting.)
But for type 1 and 2 data, the answer is anything other than easy.
Program preferences traditionally have used the "Registry" to store values.

For those who haven't come across the Registry it is a (big) file where everything from the default Word font to the hardware available is stored. This is a really important file and changes to it could stop your computer working, that said if you (in XP) click "Start" - "Run" and then type "regedit" in the box you will see the registry in all its glory, - don't change anything though!

Preference Data

Now, the first two Wessex programs (WPP1 & WPP2) stored their preferences in the registry (Visual Basic makes this easy to do using the GetSetting & SaveSetting functions), but with Wessex Premier the preferences really got too many to save in this way. Programmers have a responsibility to keep registry entries to a minimum, one reason is that the values become too unwieldy to manipulate as a whole, another is that if the program is uninstalled the entries often remain and clog up the system (I ran a registry cleaning program recently on my laptop and found over a thousand orphan entries).So, what's the alternative? The one I chose was to write a "class"(a discrete piece of code that adds functionality to the program language) which mimicked the GetSetting & SaveSetting functions but instead of saving the values in the registry - they are saved to an XML file which is easy to save, move and copy.

Let's not get too technical here - what's an XML file? XML stands for Extensible Markup Language and can take the form Key - Sub-Key - Value, eg. "Glass" (key) "Standard Glass" (sub-key), "1.2" (value). Thus making it especially useful for data files.

Temporary Data

This use of XML was very successful, so I wondered if I could use this type of file for scenario 2 (temporary data created by one part of the program and used by another)?

In Wessex Premier price & work details can be saved to a file temporarily until the customer has finalized their order, they are then saved to the database - an invoice & work tickets are printed and the files used deleted.

When the program first came out this temporary save was achieved using Text (TXT) files. These type of files have been around for years, the values are separated by quotation marks, (eg "1.2""Landscape" etc). The program knows which value is which by its position in the file (eg 6th value is glass, 7th is job description and so on). All was fine and dandy until you wanted to note the mount margins in inches, such as - 2" t & s 2.25" b. Now the extra quotation marks confuse where one value ends and another begins, the program can't decipher the values and so can't save to the database. Once this problem was pointed out I solved the problem temporarily by not allowing the user to key in quotation marks.
But by using the XML format all this is avoided - instead of dealing with a preference file "user.xml" a file called "jobs.xml" (then "job1","job2" & so on) is saved until needed by the database and then deleted.

If you want to take a closer look at XML files (& see what's inside them) search for "XML Viewer" a small, free program that is easy to use.

We can work it out

So, just how does a pricing program come up with the final price?

Well, it uses an algorithm (a set of made-up rules) to produce the answer.

The old two-way table sheet (which some framers still use) is a very simple algorithm - add the horizontal and vertical dimensions together, then go down the appropriate column adding in the various components, add VAT to get the final total.

The algorithms for computer pricing are different for each program. Some are closely guarded secrets and are very complex, while others (such as the Wessex Pricing Programs) are open and easy to understand. Because computers can work out millions of calculations a second it is tempting to make the algorithm and its application complex, in my experience this just makes the program too cumbersome to use in the real world.

I have used basically the same core algorithm in each of the Wessex Programs. It has stood up to the test of time (I'm still in business after 24 years!) so I can see no reason to change it. It is simple because (a) the user can stay in control of the pricing and (b) if the program starts to produce unexpected prices it is relatively easy to work out what's going wrong.

The algorithm I use is this - a base cost is added to the variable cost.

There, I said it was simple didn't I?!!

To put some meat on that idea's bones, imagine a piece of glass (say 10" x 8", that is 80 sq. inches) you've decided that you won't cut any piece of glass for under £2.50, and that you're going to charge glass @ 1 pence/sq. inch. So, the sum is quite a simple one 250 + (80 x 1) = 330 pence. Mounts can be worked out in the same way, while the frame itself can be a base cost + perimeter x moulding cost.

Each component can be worked out in this way, added together with VAT etc., all in a fraction of a second and with no arithmetical errors.

With me so far?

Now, if you think about it, by varying the base cost against the variable cost you can make small frame expensive and large frames cheap (high base cost / low variable cost) or vice-versa (low base cost / high variable cost). Most framers of course, go for somewhere in the middle.

So, not only is this algorithm simple - it's surprisingly sophisticated. Most importantly, however, it means that you, the framer, control your pricing, not the program.