New Program

I'm pleased to reveal that after 2 years development Wessex Premier Professional will be released at the Spring Fair in February 2010 at the NEC.
It's a major redesign of Wessex Premier, as well as being two programs in one. You can start off with the Basic version which issues prices and just uses the Mouldings part of the database. Then, when ready, you can upgrade to the Full version which keeps track of Work Tickets, Invoices and so on. All the records, labels and values from the Basic version are carried across thus making upgrading as painless as possible.


Above is a screenshot of the main form of the Basic version.
The main form of the Full version will be familiar to all who know the original Wessex Premier. Its layout has proved to be easy to use and understand as well as being versatile.

The Full version has many new features, which I won't detail here except to say that none of the features have been included for their own sake - they all help to make the program quicker, more productive and easier to use.

For those of you interested in the technical details - The program has been written in VB 2008, and uses the .Net Framework 2.0. This enables the program to be restarted programmatically, and I don't need to use a third party control for the menustrip customization.
Perhaps the bit I'm most pleased with is something you hardly notice - the buttons, I haven't counted but there must be about 50 of them in the program. Previously the graded shading on them was achieved calling a sub-routine every time the control was "painted" (ie. many time a second). Now I've written a custom control which does this and more (the lettering moves to indicate the button has been clicked and a dotted line appears when the button "has focus"). By including this new control the final compiled program was some 25% smaller, all contributing to the efficiency of the new program.


We've been using this new version of Wessex Premier in our shop since the summer and have been really pleased, I certainly wouldn't go back to the previous version.
So I look forward to talking about it to people at the Spring Fair.

A Database tweak

Fiddly things databases - just when you think you have everything just so, something else comes along to upset the balance.

I recently came across one such hiccup (or a least potential hiccup) in the "Mouldings" table of the Wessex Premier database.

The field "Supplier No" is structured not to allow duplicates. Now 99.9% of the time this will make no difference at all, in fact it can be very useful as it means that the mouldings which are duplicated between Wessex & Frinton cannot be duplicated in the program's database records. However, it could be that 2 different suppliers use the same number, or the user may want to show both the Wessex and the Frinton records.

So, how to solve the problem? I tried various programmatic solutions, but none worked consistently. So, given that most users probably wouldn't want to change the database file, what's the answer for those that do?

You'll need to use Microsoft Access (I tried this on Open Office Base, but no joy).

First of all "Export" (copy) the database file (called "V3.mdb") to a suitable location, as it's always best to work on a copy rather than the master file.

Double-clicking the file will open it in Access (assuming that is your default database program). On the left hand side you'll see a list of the tables ("Customers", "WorkTickets" and so on) Double-click the "Mouldings" table to open it. A chart with all the records will be displayed.

In the top left just above the table list is "Views", click this and select "Design View". The main window will now show a list of the fields in the Mouldings table and their properties. (see below)

Select "Supplier No". Below is a list of the properties for that field.

Select "Indexed" and change "Yes, (No Duplicates)" to "Yes, (Duplicates OK)".

"Save" the changes and you're done, all that remains is to "Import" the modified file back into Wessex Premier.

Points to note -

You should regard this "tweak" as one way only, because, once you have added a record with the same supplier number as another record, Access will not allow you to change back.

You change any of the other properties at your peril!

The above screenshot was from Office 2007, be sure, however, to save the database as an Access 2000/2003 file (ie. a .mdb file not a .mdbx file).

The steps in Office 2003 look different, but are basically the same. (If that's not too double-dutch!)

Backup or C***up?

As you continue to use Wessex Premier you accumulate data in the form of database records. Because we're using this program in the real world these records have a real importance to our businesses. In fact we would definitely have problems if the records suddenly disappeared. At the very least we would have to re-input all the moulding records and as for reconstructing the work ticket records - well, it doesn't bear imagining!

When the program was originally released there was the usual menu option to copy the database file to somewhere and a recommendation in the Help section to do this at least once a week. With 20/20 hindsight this was hugely optimistic.

Although computers and more specifically hard drives have become far more reliable over the years - them can still fail suddenly. In fact many take the view that once a hard drive is 4-5 years old you are on borrowed time.

So, what's the answer?
Of course, there are lots of answers (you knew that was coming didn't you?) and the trick is to find one that suits you.

In the (good?) old days of MSDOS you just got a bunch of floppy disks and copied the whole system onto them. With the coming of Windows that became unrealistic and just backing up (or not) your documents became the norm. With the greater reliability it was (is) very easy to let things slide and not take any precautions at all. Of course, as in other areas of life - take no precautions and you'll eventually get caught out!

After a couple of phone calls from framers telling me their computers had died, was there any way to get back their data? And no, they hadn't taken any copies! Well, I started to wonder how to lessen the worry and let the computer do the work.
The answer I came up with was to get the program to copy the database file to a specified location every time it was shut down (in most framing shops this means at the end of each day). Simple, eh? Of course it requires a bit of thought as to where the file is to be copied. The easiest being a USB flash drive permanently plugged in, or else a second hard drive in the computer (a network place should also be possible, though I haven't tried it). What you don't want to do is to copy the file to the same hard drive, because if that fails it takes your backed up file down too.

There are some points to beware of however, one is that USB flash drives can and do fail - so make sure you have a spare. The other is bit more complicated - suppose for some reason the database file you are using with the program becomes corrupted, when you shut the program down the corrupted database will over-write the previously saved good file. Not a good idea, - so if you suspect your database is not right then the correct action is to copy the backed-up file somewhere else before you shut the program down.

So much for protecting the data produced by Wessex Premier, but what about all the other important documents, photos, movies etc. that accumulate on your computer? Well, the obvious thing to do is copy them to an external hard drive (which are pretty cheap nowadays) or use another solution that I've been impressed with - namely backup to an external server. I've used Humyo (www.humyo.com) and the software they provide (so if you add or make changes to your documents these are uploaded to their servers straight away). This way, if the house goes up in flames it won't mean the lose of years of accounts, letters, pictures and so on. Another bonus is that I can access the account from any internet-connected computer - surprisingly useful.

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.

Gentlemen v Players

Do you have to be a full time programmer to write a commercial program?

This question came into focus recently after reading a report in Art Business Today on the Framing Industry Awards. The article reported a speech made by the winner of the Innovation Award (a Norwegian Visualisation & Pricing program). It was stated that this program was top because it was written by an expert professional programmer, not some "framer with an interest in computers".

Now, I was always taught to "never disparage the competition", but I feel definitely disparaged! (as should the other framer/programmers out there).

The first point I would make is that writing a program is not rocket science, any more than learning a foreign language is. Microsoft (who market Visual Basic that I write in) go to huge lengths to make their product robust and easy to use. The same goes for Borland and their Delphi language that John MacAffee's Preview & Estlite uses.

The second point is that I've more than 20 years experience in writing programs for framers. I've also attended a college course (passing with distinction) and written articles on the subject, as well as being a professional framer for over 30 years. I'm sure that similar experience goes for the other framer/programmers too. So, a bit more than a slight interest in computers then.

As for professional programmers - you've only to look at the many programs that didn't run on Vista to see that sometimes you can be too clever for your own good.

In fact, it is precisely because programming is not our main bread & butter that framers can spend a large amount of their spare time optimising their programs, time that a professional would have to be paid for.

However, the most important point is that programs written by framers for framers are easier and more intuitive to use.

A program can be the most sophisticated, all-embracing package imaginable, but if it gets in the way of your framing or your dealings with your customers - it's useless.

My philosophy is that anyone in your framing shop should be able to give a price/issue a work-ticket, from the person at the top to the Saturday-helper. This is achieved by designing the program to be easy and good to use (see previous posts). This may mean that the pricing (or visualising) algorithm is simplified in order to make things more understandable and unobtrusive to use, but if this means the user can actually understand what's going on in the program - it's a compromise I'll take any day.

You have only to look at the Norwegian website (the memorably labelled www.aditxyz.no) to see that the winning program was written by someone who has never made a frame in their life or had to deal with a customer (or with any artistic sense, but then perhaps I'm just being hyper-critical!).

One of the issues many people have with programs is "bloat", which means that the program contains many features (which you've paid for) that you'll never need (MS Office immediately comes to mind - why not use Open Office for free?). Of course a feature you'll never use is another's must-have, but surely this emphasies even more the need for roots within the framing industry?

So - if you're in the market for framing software - beware and be wise!

A more sophisticated way of importing a database

The current Wessex Premier has a very simple way of checking a database to import - if it's not called "V3.mdb" it won't be imported. Now this works at a very simple level, but it leaves two problems

The first is that all the backed up files have to be called "V3.mdb" (rather than anything more convenient like say "ShopBackup_16_6_09.mdb"). You can get round this by renaming the file after exporting and back again before importing, but this is an awkward and fiddly way of dodging the issue.

The second problem is that although the file might be called "V3.mdb" the internal structure of the database (called the "schema") could have been changed and this would make it incompatible with the program.

So, is there a way of checking the schema of each table against a master schema-file?

There is, of course, otherwise I wouldn't be writing this!

This first thing to do is to extract the schema from the file to be imported. The crucial line of code is this -

dstSchema.Tables("V3Schema").WriteXmlSchema(xmlWriter)

Which writes the schema to a temporary (xml file) to compare against master xml schema.

Then the temporary file is then run (byte by byte) with the master file and each byte is compared, if they don't match then the file to be imported is rejected. The heart of the code is this -

Do

MasterByte = MasterStream.ReadByte 'master table

CheckByte = CheckStream.ReadByte 'table to be imported

If MasterByte <> CheckByte Then

blnOk = False

Exit Do

End If

Loop While MasterByte <> -1

This is done for each of the four tables in the program's database, as long as the file-to-be-imported passes the test it can be imported (its name is changed to "V3" for internal use).

Obviously there is a lot more code to set up the above lines - checking that the files exist, that the user hasn't pressed "Cancel" as so on - but in testing I haven't yet come across any problems, so it looks like this feature will be in Wessex Premier II.

Sneak preview

"So, what are you working on now?" is a question I've often been asked at the Spring Fair.

The answer is a completely rewritten Wessex Premier. The basic idea being 2 programs in 1 - a basic frame pricing version which uses just the mouldings part of the database, but no worktickets or customers list. This could be upgraded to the full version when the user needs to - using the same database that has been built up. In this way one could get use to using the program just to give prices, and because it works in exactly the same way as the full version it will be much more straightforward to upgrade - you wouldn't even need another disk.


Another aspect I'm working on is improving the handling of database records, particularly worktickets, in the full version. At the moment in WPP3 the lists of work to be done, low moulding stock etc. are separate from the records themselves (ie. you have to close down the list having made a note of the record, then go to the record itself. Not very efficient.) Now you will be able to look at the list, double-click on the line of interest and the individual record will come up. Also, visually, the workticket list is easier to read being in name order with the Overdue, For completion and Completed jobs in different colours.

The third big change is adding mountboards to the database. The idea behind this is to record the mountboard colour in the database and then print a spot of that colour on the workticket. This way mistakes can be minimised (for instance Aqadia 8643 in quite a different colour to 8043).

To make everything even more foolproof when the list of mount colours comes up each line is the colour of the mountboard. It was an interesting piece of programming as the lettering (normally black) has to change depending on the lightness/darkness of each colour.

Now I'm at the stage of "tweaking" the program, for instance - if when you click on a workticket, do you want all the other worktickets on that same invoice to appear, or does that just complicate the process? Is putting the mount colours on the workticket actually an advantage? Only by using the program for real do these thing emerge.

There is a technical price to be paid however. Whereas the current Wessex Premier (WPP3) uses VB2003 with the .Net Framework 1.1 (a quick install). This new program is written in VB2008 and uses the .Net Framework 2.0 ( a much longer install), which is needed because the program has to shut down and restart (when switching between versions) and also for the new menu controls.

Another reason for going with the new program is better integration with Windows Vista & Windows 7 (here at the end of October). While at the moment most people use XP, as computers get changed and upgraded those using XP will get less and less (in fact Microsoft plan to stop supporting XP completely in 2014).

Will the new program see the light of day? We'll have to see!

Some history, - in the beginning - - -

Way back in the days of the ZX Spectrum (over 25 years ago now) I was shown the basics of programming by the teenage sons of a colleague. It occurred to me that this would be an ideal way of pricing picture frames. Upto that point we had used a 2 way table - add the horizontal and vertical measurements together, then go down a column adding in the various items. This, of course regularly produced mistakes in the addition and the customers, looking at the long list charges, often wanted to know what each item was. The new simple program for the Spectrum solved all this, after a few key presses the price appeared on the screen, and the customers said "Yes please". I think I must be one of the few people who used the Spectrum for business rather than games!

For those who don't know of the Sinclair ZX Spectrum it was about the size of today's tablet PCs. It plugged into a TV and stored its programs on a cassette tape. The weakness was its keyboard, the rubber membrane kept giving up. After I got through 3 we bit the bullet and bought a PC (about £1000 20 years ago). This meant the program was rewritten in GW Basic and then with the coming of Windows 3.1 -QBasic. With each rewrite extra features were added.
There was none of the pretty interface of today, and the mouse was superfluous. To change the parameters you edited the program code directly (not quite the problem it appears as QBasic was bundled with Windows 3.1). It did show the way, however, so when I got hold of VB6 it was a revelation - you could, with a bit of work, produce a program that looked professional, was reliable and could easily be packaged for other people's computers.

The result was what came to be the original Wessex Pricing Program (wpp1). I took the CD along to the Spring Fair to show Wessex Pictures, and the rest, as they say, was history (actually it was the start of a steep learning-curve which is still going on).
The proof of the pudding is that the program is still regularly sold by Wessex.
More recent history will be covered in another blog.

nb. There is an update for wpp1 to allow for the increase in moulding costs since the CDs were originally printed - go to www.wessexpictures.com.

Troubleshooting bulk update

Wessex Premier is able to perform a bulk update on Wessex & Frinton moulding records. It's very useful to, say, add all the mouldings from Wessex (as, after all, you can order just one length with your weekly delivery). But as the list consists of somewhere in the region of 1300 records this is where the update-from-file comes in.

The program has proved to be very reliable in this area (you download the update files from the www.wessex.com, tell the program whether you want to just update the existing records or to update and add everything else, then navigate to the downloaded files and press go).

One point to note is that Wessex & Frinton share some mouldings (actually over 200), these are the "WFxxx" and "PWxxx" ranges. So, if you already have them listed under (say) Wessex when you update the Frinton section the program will report that it cannot add duplicate records.

Any problems that have arisen have always been to do with the update file itself. These files are in "Excel" format and are prepared by hand at Wessex, so one problem has been where an expected value hasn't been entered (usually the price has been left blank). Now, whilst the program updates now have more code to cope with this, it can cause the bulk update to stop.
The answer is to open the file with Excel and look for the blank values and then either - delete the line, or - put in a sensible value, save the file and rerun the bulk update. 9 times out of 10 this fixes the problem.
However, we did have one brainteaser where there was a whole blank line at the end of the file!
So that blank line had to be deleted, very strange getting your head around deleting something that wasn't there!

Designing the Wessex Premier GUI

A program can be amazingly sophisticated but unless the user can easily operate it then it's pretty useless. This is where a well designed GUI (graphical user interface), or in other words a good looking, easy to understand main form comes in.

The Wessex Premier main form is that shape because it is logical to start entering data from the top and with each new type of data continue downwards, finishing with what we all want to know - the total price.
Also it is important to stop the operator accidentally entering data that the program does not expect. For instance the top two size boxes will only accept numbers or a decimal point. The moulding boxes will only allow upto 5 characters (the maximum allowed for a moulding ID.) plus lower case letters are converted to upper case.
Next to the total price button is shown the quantity. Which is a numeric up/down control, numbers are changed using the small arrows rather than allowing the operator to enter them directly.

Those Visual Basic aficionados amongst you will have noticed that the buttons have a non-standard appearance. This is achieved programmatically rather than using bitmaps - the same goes for the graded background. The total effect is (I think) one of good design which helps promote intuitive usage as well as looking right in a sophisticated retail environment.

Whilst the most used part of the program is designed to be as quick & simple to use as possible, other parts the GUI is used to slow down the operator and give them pause for thought. One example is saving of the Options form.
It is purposely meant to be slightly out of the ordinary so the operator has to pause to decide what's going on, and in doing so may save themselves from making a mistake.

Of course what is invaluable is being able to test the program in a real environment with operators who don't really care how it works, just as long as they don't get into a mess with it! Here, the most lowly member of staff is as important(if not more so) than any number of "experts", because they are the ones who will produce the combination of keystrokes and mouse clicks that these experts haven't even conceived of!

Optimizing for Vista

It's taken quite a long time to get my hands on a computer capable of running Vista, a couple of months ago I managed it.
The obvious thing to do was to check that all the Wessex Programs worked. They did - WPP1 & WPP2 (written in VB6) had no issues. WPP3 however threw up a couple of interesting things.
The first was the graded colour background to many of the forms which finished (in Vista) before the bottom border. This is because the Menu & border widths are smaller in Vista, so I had to find code that would allow for XP & Vista. This turned out to be (instead of hard-coding for the physical width of the menu & border) to use "Me.DisplayRectangle.Height".
The 2nd issue was when opening another program (PDF reader or Media player) an error message appeared saying no application was associated with the process - the application then went on to open correctly! Annoying or what?
After a bit of digging I found the answer in "VB 2008" published by Wrox (it also applied to VB 2003 that WPP3 is written in). It was to add 1 line of code -
" myProcess.StartInfo.Verb = "Open"" It works without this line in XP, why does it need it in Vista?
Along the way I also tried a preview of the upcoming Windows 7 (Vista as it should have been) and found the programs were fine with that too.
So - Wessex now have the modified WPP3 (version 3.2.1) and all's well ?!

View of Programs

The original Wessex Pricing Program(WPP1)


Wessex Pricing Program Advanced (WPP2)



The main form of Wessex Premier (WPP3)

.