Well, with the new year looming and the showcase of the 2011 SpringFair at the NEC just over the horizon it seems a good time to review how things have gone with Wessex Professional that was released at the SpringFair 2010.
I'm pleased to say that the program has been very well received with comments and suggestions all positive ones. The feedback I get from clients really does help to make the program easier to use and smooths any rough edges. It also sorts out any mistakes or glitches too.
As an example, the version of the program to be shown at the NEC will be 4.1.2. These last changes came from a conversation with a client who uses the "Guest" moulding facility a lot.
For those who haven't come across this feature - if the moulding is not in the database the user can type "Guest" in the moulding box and a form will appear (when "Total Price" is clicked) asking for the width and price/mt. to use. The program can then work out the cost as usual.
Because I don't use this very often I hadn't really thought out the process and had ended up with something that was a bit "clunky".
The client pointed out that the amount of the Guest moulding needed wasn't printed on the workticket and that if you changed something on the main form you had to enter the Guest details all over again each time you clicked "Total Price".
She also revealed that there was a discrepancy between the quantity shown through the main form and that shown on the workticket. Oh, and by the way it would be good if when you started entering the customer details at various points in the program the name shown was at the top of the list (rather than the bottom) so you could see if you had more that one of the same name in the database, (fairly obvious with "Smith" or "Jones" but less so with, say, "Younger").
After getting over the "Why didn't I think of that?" A fortnight later the a new version of the program was made that - Corrected the quantity problem, showed the Guest quantity on the workticket, made it so you didn't have to enter Guest details over and over, put the customer name you were seeking at the top of the list and, while I was about it, I made it so if you were scrolling through the worktickets or mouldings and selected a record after you closed that record you are now returned to where you had scrolled to, rather than the top of the list. Phew!
I really feel that I can go on the stand at the NEC in Feb. and say that Wessex Professional is the best, most straightforward, most user-friendly pricing/database program for framers on the market today.
This blog is about developing the "Wessex Pricing Programs", with in-depth consideration of why features work as they do, as well as the history & future development. Mostly the blog will be about "Wessex Professional" (WPP4) the most sophisticated of the four programs. I am by profession a bespoke picture framer (for the last 30 + years). But I have been interested in programming since Sinclair Spectrum days and have become a passable programmer in Visual Basic.
Thursday, 16 December 2010
Thursday, 23 September 2010
Vista & Win 7 - revisited
I've already posted about changes needed for post XP operating systems (ie. Vista & Windows 7). There was, however, an elephant in the room - namely UAC (User Access Control) introduced with Vista.
Now UAC has a lot of aspects, but from a programmer's point of view a major one is needing administrator privileges to write to (make changes to) the Program Files folder. Now, a programmer has a nice warm feeling when all the files that their program needs are in one folder (Program Files > Wessex Pictures in my case). It means they are easy to keep track of and in Windows XP there was no problem setting up your program this way (though whether it was the recommended way is another matter).
Most programs, and the Wessex Pricing Programs are no exception, need to record settings a user makes to configure the program for their use. As far as Wessex Premier & Professional are concerned this includes the labels/values file and the database file itself. Both of these files get written to (ie. changed) a large number of times while the program is in use.
So, these files needed to be set up in another location. The "My Documents" folder is really just too easy to change or "fiddle" with. Microsoft have provided a number of folders that could be used and the one I selected was the Common Application Data folder.
Theoretically, all I had to do was change the sub-routine that returned the path to the Wessex Pictures Program Files folder to point to the Common Application Data folder. Too easy you're thinking - and of course it was. The problem is that in the CommonAppData folder there is a Wessex Pictures folder and within that a WPP4 folder and within that a folder for each "build" of the program, with the code that returns the path to the CommonAppData returning the path to that "build" folder. So what's the problem? Well, if the user installs an updated version of the program it will use a new "build" folder, but the database & user files will be in the previous folder. What is needed is to modify the code to return the folder up from the one returned by the straightforward code (ie. site the files outside the build folders, but inside the WPP4 folder. (see screenshot)
In the above screenshot you can see there are 3 build folders, with the data files outside of them, but within the WPP4 folder.
That crucial line of code is -
Dim dirPathParent As DirectoryInfo = Directory.GetParent(Application.CommonAppDataPath)
It's the "Directory.GetParent" bit that does the business. As with all simple things it took a bit of working out, I couldn't find that anyone else had posted about the problem. What started as some quite elaborate code which searched the folders for the specific files, compared their dates and then moved the latest ones to the new folder, turned into just one extra line.
All that was needed now was some tricky "If" statements checking if the data files were in the old location but not the new location, Then copy the files over. This ensured that users updating the program weren't involved in complex file copying in places they didn't know existed on their computer.
Does it work? It was with some trepidation I installed the update at work (after all it's one thing working in the programming environment and quite another using and letting others use the program for real). I double-clicked the icon on the desktop - the program started and I quickly checked through the database & values - it was all there, pheeew!
This will be the version (4.1.0) that will, finally, be on the Wessex Pictures website for download.
Now UAC has a lot of aspects, but from a programmer's point of view a major one is needing administrator privileges to write to (make changes to) the Program Files folder. Now, a programmer has a nice warm feeling when all the files that their program needs are in one folder (Program Files > Wessex Pictures in my case). It means they are easy to keep track of and in Windows XP there was no problem setting up your program this way (though whether it was the recommended way is another matter).
Most programs, and the Wessex Pricing Programs are no exception, need to record settings a user makes to configure the program for their use. As far as Wessex Premier & Professional are concerned this includes the labels/values file and the database file itself. Both of these files get written to (ie. changed) a large number of times while the program is in use.
So, these files needed to be set up in another location. The "My Documents" folder is really just too easy to change or "fiddle" with. Microsoft have provided a number of folders that could be used and the one I selected was the Common Application Data folder.
Theoretically, all I had to do was change the sub-routine that returned the path to the Wessex Pictures Program Files folder to point to the Common Application Data folder. Too easy you're thinking - and of course it was. The problem is that in the CommonAppData folder there is a Wessex Pictures folder and within that a WPP4 folder and within that a folder for each "build" of the program, with the code that returns the path to the CommonAppData returning the path to that "build" folder. So what's the problem? Well, if the user installs an updated version of the program it will use a new "build" folder, but the database & user files will be in the previous folder. What is needed is to modify the code to return the folder up from the one returned by the straightforward code (ie. site the files outside the build folders, but inside the WPP4 folder. (see screenshot)
In the above screenshot you can see there are 3 build folders, with the data files outside of them, but within the WPP4 folder.
That crucial line of code is -
Dim dirPathParent As DirectoryInfo = Directory.GetParent(Application.CommonAppDataPath)
It's the "Directory.GetParent" bit that does the business. As with all simple things it took a bit of working out, I couldn't find that anyone else had posted about the problem. What started as some quite elaborate code which searched the folders for the specific files, compared their dates and then moved the latest ones to the new folder, turned into just one extra line.
All that was needed now was some tricky "If" statements checking if the data files were in the old location but not the new location, Then copy the files over. This ensured that users updating the program weren't involved in complex file copying in places they didn't know existed on their computer.
Does it work? It was with some trepidation I installed the update at work (after all it's one thing working in the programming environment and quite another using and letting others use the program for real). I double-clicked the icon on the desktop - the program started and I quickly checked through the database & values - it was all there, pheeew!
This will be the version (4.1.0) that will, finally, be on the Wessex Pictures website for download.
Wednesday, 30 June 2010
Stock control - does it work?
It's that time of year again, and my "favourite" job - stock taking! But it does mean that I've got a chance to check the stock figures produced by the program (WPP3 or WPP4) against the true moulding stock.
Now you've only got to think a moment to realise that trying to keep track of moulding stock with a computer program is fraught to say the least.
On the face of it all the program has to do is work out how much moulding it's going to use for a particular job (plus, perhaps, a percentage waste), and take that off the existing stock figure - simples?!
Well, no, actually.
First of all the database of mouldings has to be updated each time more stock comes in.
Then how do you account for warped or damaged moulding? You could unwrap each length and carefully inspect it, but, unless you wrap it up again, you're asking for the unwrapped moulding to be scraped, scratched or worse.
Lastly, the moulding could be from different batches which are not compatible. Try telling the program that!
Of course it would be possible to write the program to take account of all the problems, but I think that it would make things so complex that no one would bother trying to keep the stock figure correct.
So, the Wessex Programs tries to keep the stock control simple, keeping it is easy to understand. But this does mean that common-sense also has to be used to keep the figures adjusted and up to date. With a little application you'll find that the moulding stock part of the program is more of a help than a hindrance. I'll give two instances
Well, surprisingly close, and what was even better - after the upto date figures had been entered the total value of the stock was there already worked out saving hours with a pen and calculator.
Now you've only got to think a moment to realise that trying to keep track of moulding stock with a computer program is fraught to say the least.
On the face of it all the program has to do is work out how much moulding it's going to use for a particular job (plus, perhaps, a percentage waste), and take that off the existing stock figure - simples?!
Well, no, actually.
First of all the database of mouldings has to be updated each time more stock comes in.
Then how do you account for warped or damaged moulding? You could unwrap each length and carefully inspect it, but, unless you wrap it up again, you're asking for the unwrapped moulding to be scraped, scratched or worse.
Lastly, the moulding could be from different batches which are not compatible. Try telling the program that!
Of course it would be possible to write the program to take account of all the problems, but I think that it would make things so complex that no one would bother trying to keep the stock figure correct.
So, the Wessex Programs tries to keep the stock control simple, keeping it is easy to understand. But this does mean that common-sense also has to be used to keep the figures adjusted and up to date. With a little application you'll find that the moulding stock part of the program is more of a help than a hindrance. I'll give two instances
- When you give a price the program looks at the moulding stock figure. If that figure is less than the low stock threshold (I have mine set at 3 Mt - roughly 1 length) then a warning is flashed up, so you know to check the actual stock before committing to a completion date.
- If you are ordering from a particular supplier you can look at the "Low Stock" list in the mouldings database. This shown by supplier so you can see other mouldings to order, perhaps making up a carriage paid order rather than a piecemeal series of orders.
Well, surprisingly close, and what was even better - after the upto date figures had been entered the total value of the stock was there already worked out saving hours with a pen and calculator.
Tuesday, 30 March 2010
Will it run on a Mac?
I guess the most common question we get asked about the Wessex Pricing Programs is "Will it run on a Mac?"
The short answer is "No.".
The long answer is "Very probably.".
The problem is that the Mac operating system and the Windows operating system are very different from each other. They won't recognise each other's files or know how to execute them. Things have got a little easier now that Apple has moved to an Intel processor, but there is still a big gulf between the systems (and, for that matter, Linux, a third system, but see the footnote at the end for that.)
Now, before we go any further, I will nail my colours to the mast and say that I've never used a Mac, so all that follows is from a Windows perspective and I apologise now if I've got anything wrong.
It seems that there are three main ways of getting a Windows program to run on a Mac.
The first is "dual boot". This means that both Windows and the Mac operating systems are on the computer, and you have to choose one or the other when the computer starts. (I believe there is a utility on the Mac called "Boot Camp" that assists with this.) There are two obvious problems with this - a) you can't easily switch between systems, b) you have to buy both systems.
The second way is "Virtualisation". This means you can have Windows running within the Mac system and can switch quite easily between the two. However, you still need to have a full copy of Windows, and the "VM" (virtual machine) software is not the easiest thing in the world to use.
Now we come to the third way - software that will translate the Windows code into something the Mac will understand.
This is where a program like "Crossover Mac" comes in (http://www.codeweavers.com/products/cxmac/ ) Although I haven't used it myself, I have looked at the details and it seems to tick the right boxes. There's a free trial to check that it will actually work and it's reasonably priced if you do decide to buy.
At the beginning of this post I mentioned another operating system - Linux. This comes in lots of varieties, the most popular at the moment being "Ubuntu". The reason I mention it is that it's very secure (based on the Unix mainframe system) and it's free (together with most of its software). As long as you are just using standard office type tasks the system is easy to use. There are the same problems getting Windows programs to run as with a Mac, and the same solutions exist. There is a program called "Crossover Linux" and also a free solution "Wine" - I must get tinkering!
The short answer is "No.".
The long answer is "Very probably.".
The problem is that the Mac operating system and the Windows operating system are very different from each other. They won't recognise each other's files or know how to execute them. Things have got a little easier now that Apple has moved to an Intel processor, but there is still a big gulf between the systems (and, for that matter, Linux, a third system, but see the footnote at the end for that.)
Now, before we go any further, I will nail my colours to the mast and say that I've never used a Mac, so all that follows is from a Windows perspective and I apologise now if I've got anything wrong.
It seems that there are three main ways of getting a Windows program to run on a Mac.
The first is "dual boot". This means that both Windows and the Mac operating systems are on the computer, and you have to choose one or the other when the computer starts. (I believe there is a utility on the Mac called "Boot Camp" that assists with this.) There are two obvious problems with this - a) you can't easily switch between systems, b) you have to buy both systems.
The second way is "Virtualisation". This means you can have Windows running within the Mac system and can switch quite easily between the two. However, you still need to have a full copy of Windows, and the "VM" (virtual machine) software is not the easiest thing in the world to use.
Now we come to the third way - software that will translate the Windows code into something the Mac will understand.
This is where a program like "Crossover Mac" comes in (http://www.codeweavers.com/products/cxmac/ ) Although I haven't used it myself, I have looked at the details and it seems to tick the right boxes. There's a free trial to check that it will actually work and it's reasonably priced if you do decide to buy.
At the beginning of this post I mentioned another operating system - Linux. This comes in lots of varieties, the most popular at the moment being "Ubuntu". The reason I mention it is that it's very secure (based on the Unix mainframe system) and it's free (together with most of its software). As long as you are just using standard office type tasks the system is easy to use. There are the same problems getting Windows programs to run as with a Mac, and the same solutions exist. There is a program called "Crossover Linux" and also a free solution "Wine" - I must get tinkering!
Tuesday, 16 February 2010
Networking
I thought that it would be useful to write a post detailing the steps to prepare Wessex Premier & Professional to work over a network.
I've suggested in the Help files that networking is still very much a "Dark Art" and even with the coming of Windows 7 I haven't changed that view. There are just too many obscure acronyms and settings for most normal people. So, you might find it advantageous for your sanity to have a network expert to actually get the computers "talking" to each other.
When I talk about networking these programs I'm assuming, say, a computer in the shop and another in the workshop, certainly not more than five computers anyway.
>As far the Wessex Professional & Wessex Premier are concerned the concept is as follows – There is a “Master” computer (usually the one which will issue the prices & print off the invoices), this will hold the database file to be used over the network. The Master computer is networked to one or more “Slave” computers, they also have a copy of the program installed. But instead of using their own database the “Use network database” box is ticked, the path to the master computer's database is recorded and that file used instead
All this is achieved by-
NB. The labels and values in all the computers should be the same. This is easily achieved by going to "Values" and clicking "Backup" on the master computer, and copying the file (User.xml) to a memory stick. Then, on the slave computer(s) going to "Values" and clicking "Restore" and copying that file onto them.
I've suggested in the Help files that networking is still very much a "Dark Art" and even with the coming of Windows 7 I haven't changed that view. There are just too many obscure acronyms and settings for most normal people. So, you might find it advantageous for your sanity to have a network expert to actually get the computers "talking" to each other.
When I talk about networking these programs I'm assuming, say, a computer in the shop and another in the workshop, certainly not more than five computers anyway.
>As far the Wessex Professional & Wessex Premier are concerned the concept is as follows – There is a “Master” computer (usually the one which will issue the prices & print off the invoices), this will hold the database file to be used over the network. The Master computer is networked to one or more “Slave” computers, they also have a copy of the program installed. But instead of using their own database the “Use network database” box is ticked, the path to the master computer's database is recorded and that file used instead
All this is achieved by-
- Install the program on each computer (you will need an enabling code from Wessex for each one.
- On the master computer navigate to "All Programs" - "Accessories" - "Windows Explorer". Then, on the left hand pane (in Windows Explorer) go to "My Computer" - "C:" - "Program Files" - "Wessex Pictures". Right-click on this folder, then select "Sharing & Security". Tick "Share this folder on the network", also select the permissions you want (ie. whether the slave computers(s) can modify the files). Click "Apply".
- On each of the slave computers tick the "Use networked database" box (in "Setup" - "Options"). Then click the "... locate network database." label. With the dialog box - on the left hand pane select "My Network Places" and the shared folders will appear. Double-click the Wessex Pictures folder, keep double-clicking until a screen with 6 folders (4 in Wessex Premier) and a file titled "V3" appear. Highlight "V3", then click "Open". The dialog closes and the path to the database is shown (it will be something like "\\main\wessex pictures\Wessex Professional\V3.mdb")
- Click "Save" on the Options form and close it. The slave computer will now use the master computer's database.
NB. The labels and values in all the computers should be the same. This is easily achieved by going to "Values" and clicking "Backup" on the master computer, and copying the file (User.xml) to a memory stick. Then, on the slave computer(s) going to "Values" and clicking "Restore" and copying that file onto them.
Friday, 8 January 2010
"I didn't know you could do that."
Some tips & tricks that make Wessex Premier easier to use.
- Use the "Tab" key to move from box to box on the main form - its been designed to move in a logical order and is quicker than using the mouse.
- After clicking "Total Price" hold the cursor over the Moulding ID box and it will give you the Supplier & the Supplier Number - the new WPP4 will also show the quantity needed and how much is in stock too.
- Moulding not in the database? - Type "GUEST" into the Moulding ID box, then when you click "Total Price" you will be asked for the width (in Mm) & price (per Mt.) and the program will work out the price.
- Want to give the customer a special price? In the new WPP4 you can double-click the total price box and then enter the agreed price (it will be shown in green as a prompt, and blue if the minimum charge has been applied).
- Using the "Enter" (Return) key is the same as clicking "Total Price", but quicker.
- Press the "Esc" key to clear the form, again quicker than using the mouse.
- "Alt" + "R" is the same as pressing the "Reset" button in Wessex Premier & the Full version of WPP4.
Subscribe to:
Posts (Atom)