Size Matters

 I'm sure that you have noticed that the size of the Wessex Pricing Program is fixed. There is a reason for that (skip the following paragraph if the brain is feeling a bit tired).

Computer screens are not only measured by size (usually diagonally across the screen) but also by "resolution" stated in "pixels". The more pixels the better detail that the screen can show. The computer I'm writing this on has a resolution of 1920 x 1080. Not too many years ago a resolution of (say) 1200 x 800 more would have been considered good. When you set a size for a form in a program it is set in pixels, not inches or Cm. So it will look smaller on a higher resolution screen, and larger on a lower resolution screen. 

Wessex Professional has stayed the same size ever since it was released. This way it would be good for older monitors. However, the difference between old and new monitor resolution is becoming quite pronounced and although there are things you can do to show the program at a larger size, what is really needed is the ability to resize the program to suit your screen. This is easier said than done. There are at least 27 "controls" (buttons, textboxes and so on) in the main screen and each one needs to be resized in proportion to its neighbour.

The problem is finally solved in the latest version (4.4.12). You can now resize and reposition the main form to suit your screen and the program will remember that for the next time.

The above screenshot shows the standard size, with the program always starting centre-screen.

This screenshot shows the program enlarged and repositioned. It will remember the size and position for next time it starts.

By the way, the computer these screenshots were taken from is running Windows 11. Wessex Professional is perfectly happy running on that.

Also in the new version is an improved "Moulding Needed" section ("Tools" > "Mange Database" > "Mouldings", click "Views" and choose "Moulding Needed" to show the moulding you'll need for your current jobs, and which you're likely to have to order).

The "Save invoice as PDF" in the Print section has had some potential errors corrected and should be more consistent. 

All that remains is to wish everyone a Happy and Prosperous New Year.

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.

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.

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 ?!