Tuesday, March 31, 2009

Driving Tips to Save Fuel

From www.greatdriver.co.uk: "Always try and use the vehicle controls as smoothly as possible, with particular attention to:
  • starting and moving away
  • accelerating
  • using gears
  • driving at an appropriate speed
This reduces wear and tear on your vehicle and will help in reducing CO2.
Planning
Reduce harmful emissions by anticipating road traffic conditions and acting in good time, rather than reacting to them at the last moment, especially:
  • showing hazard awareness and planning
  • making use of engine braking
  • stopping the engine when appropriate
Tips for ‘eco-safe’ driving and riding
Follow these tips as a guide to safe driving or riding for economy:
  • check your tyres regularly and keep at recommended pressure
  • don’t carry unnecessary weight
  • remove roof-rack or luggage boxes when not needed to reduce air resistance
  • don’t exceed speed limits
  • accelerate briskly
  • consider using cruise control where it would be appropriate
  • turn off your engine if you’re likely to have a prolonged wait
  • use air conditioning only when you need to
  • plan your route to avoid known congestion points
  • try to travel during off-peak times
Further information on eco-safe driving and riding is available in leaflet ‘Eco-Safe Driving - a guide to safe driving/riding for economy’."

One aspect of vehicle acceleration that is counter-intuitive until it is correctly explained is this: your engine is at its most efficient when the throttle is wide open, because the "throttle" is there to starve the engine of air, such as when the engine is idling, i.e. the engine is running in its least efficient state.
When you put your foot on the accelerator it uses more fuel, but the engine is at its most efficient, so the idea is to accelerate briskly until you reach the desired speed, and then change to a high gear so it uses the least amount of fuel. Obviously accelerating too fast puts strain on the car, but accelerating too slowly uses extra fuel, because you are accelerating and the throttle is partially closed so the engine is not being efficient.
So if you accelerate rapidly for a short period of time the engine is being used efficiently and you aren't using up too much fuel. Weird, but true.

Thursday, March 26, 2009

Microsoft Access and the Ten-Year-Old Currency Bug

Today I wasted hours of valuable time fighting with a bug that is in Microsoft Access 97 and can also be found in Microsoft Office Access 2007. Does it really take more than 10 years to fix a bug like this, or is Microsoft just deaf? You decide.
This is how you get the bug to work:
1. Change your regional and language settings to "English (South Africa)" so that your currency fields use the "R" symbol.
2. Create a table with some fields in it. Include two currency fields, Field2 and Field3.
3. Populate the table with a few rows of data
4. Create a report, and make sure that the format of Field2 and Field3 is set to "Currency".
5. To be extra sure, include the following code in the Report Open event:
Report!Field3.format = "Currency"
6. Preview the form. Close the database.
7. Change your regional and language settings to "Zimbabwe", so your currency is now "Z$".
8. Open the database, create a form, and put the currency fields on the form.
9. Make sure both currency controls have their format set to "Currency"
10. To make extra sure, put the following code in the form open event:
form!Field3.format = "Currency"
11. Put a button on the form to preview the report.
12. Set the database to open the form on opening the database.
13. Preview the form.
14. Close the database, and change the regional and language settings to "English (Ireland)"
Theoretically, all the controls with the Currency format should show their values in Euros, the currency for Ireland. Wrong.
As you can see from the screen shots shown here, Access converts the format from "Currency" to "R #,##0.00;R-#,##0.00" for the fields that were edited when the settings were South Africa, and "Z$#,##0.00;(Z$#,##0.00)" for the Zimbabwe settings. Only if you use code to force the control to retain the "Currency" format, does the formatting work correctly. That's why Field3 displays correctly but Field2 does not.
Why does it do it? Because Access is written by programmers in Redmond, USA, who seem to think that Canada and Mexico are on other continents, and don't realise that Redmond is not the centre of the universe and that most of the planet does not format its dates as mm/dd/yyyy. But that's another bug.
Now you can change your currency settings back to what you normally use, and shake your head in disbelief. This bug works in all version of Access from 97 to 2007. It was reported in January 2004 applying to "Access 2 and above" by Allen Browne. I guess it might be fixed in a decade or so.
Update Friday 27 March: I tried doing a loop through all the report controls, but you can only do that in design view, not in print preview, so I used the Tag property and stored the names of all the Currency controls in a tag item. Then I use the OnOpen function to set the format of the explicitly listed controls. I use a similar technique for forms. This bug (or is it an undocumented feature?) has cost me 2 days worth of programming time. Thanks for nothing, Microsoft! Both of these bugs are not documented anywhere on the Microsoft site or in the Access documentation that I could find.
Update Saturday 28 March: Setting the currency fields in the table to have a format of "Currency" doesn't work either. It seems that anything done at design time is likely to fail. What's worse is that Access lies about the format setting. It will display the format property as "Currency" when it isn't stored that way. You can expose this lie only by changing to a different region, and then inspecting the format property again. By then it's too late because the app is already installed in another country on a customer's machine, and they are yelling at you on the phone. Access 2007 also has a format called "Euros" just to add to the confusion.
The code I use in the OnOpen event is basically this
'
'// Fix up CURRENCY formatting
'
Dim strField as string, strTag as string, n as long
strTag = Nz(form.Section(acDetail).Tag, "")
If Len(strTag) > 2 Then
strTag = strTag & ","
n = InStr(1, strTag, ",")
While n > 0
strField = Mid$(strTag, 1, n - 1)
strTag = Mid$(strTag, n + 1)
form(strField).Format = "Currency"
n = InStr(1, strTag, ",")
Wend
End If
This code relies on the tag in the form detail having a list of fields, separated by commas, that require correct currency formatting. Similar code works in the OnOpen event of a report.
One final thought: I don't hate Microsoft, or Access. I have used Access 97 almost every day since I bought it in 1998 and installed it on Windows 98. Access is awesome, in spite of these annoyances. As a programmer I am in awe of all the things it does. Why they have to spoil it with undocumented nonsense that persists for 10 years is incomprehensible to me. I guess geeks aren't perfect either.
Update Sunday 29th March: Wayne Phillips sent me another elegant solution. I haven't tried it yet but it looks promising. I am al;so dismayed to find that the same bug exists in Excel, so I guess it's never going to be fixed, or documented.
Update Wednesday: Here is a comprehensive list of similar Access "gotchas" (i.e. Momentary Lapses of Reason on the part of Microsoft). I cannot believe the arrogance of these people. And as for the Dollars vs Lira argument, I can't believe that ANY competent programmer would have a "Currency" format that was not hard wired to $ or Lira if the possibility of confusion could arise. Microsoft themselves have now introduced a "Euros" format for precisely this problem, but have left the old "Currency" behaviour permanently broken. PEBCAK indeed: the only debate is whose chair and keyboard? I say Michael Kaplan's chair and keyboard, not mine. And when are they going to WTFM to document it correctly?

Monday, March 23, 2009

The Next Green Car? 50mpg is a good start

The Tata Nano's price and specifications are impressive: this car costs new what many used cars exceed: INR 100,000 or USD 1,953 or ZAR 18,850. My used Nissan cost more than that! And my car doesn't get 50 mpg or weigh only 580kg.
So why the fuss about congestion and more pollution? If every passenger car on the road in Europe, America and South Africa were replaced with one of these the congestion and air pollution would decrease, and fuel consumption go down, not up. Gas guzzlers like mine need to be replaced by vehicles like this, and the money saved by not having to pay 10 times or more for a vehicle could be used to grow the economy.
Now all we need is an electric version, and the world would be a better place. Companies like GM who can't innovate like this deserve to be put out of their misery.


Sunday, March 22, 2009

Acronis True Image Home 2009 and the feature that is really a bug (Updated)

I promised the Acronis support team that I would test Acronis True Image Home 2009 build 9709 on my laptop because they had said
I understand your issue and assure you of a quick resolution for the same. The time variation in progress bar might take place because of particular software/hardware configuration. There may be some applications running on the background that may have higher priority level than Acronis software.
Clearly they did not understand the issue because I was running from their boot CD and so there were no background applications. But to disprove the "particular software/hardware configuration" nonsense I ran the software on my Acer Extensa 5620 last night. (See below for the same bug on my FRAGG desktop machine.)
My first problem was getting the software to see the drive, because I protect it with a password. After removing the password we were ready to go. I selected all the partitions on the drive, and asked for a sector-by-sector backup, as before. Here is the summary screen:
The progress bar appears to work OK, with the top one moving faster than the bottom one, but not for long.
The overall time estimate has dropped from 10 minutes to 17 seconds, when it still has over 4 hours to go.
Notice how the total progress bar resets itself for the verification operation. Why?
To add further lunacy to the equation, the verification estimate jumps from 10 days to 3 minutes. It actually took 65 minutes.
Now for the final amazing feature: I selected the "Shutdown the computer after completion" option because it was late and it would have been nice to leave the computer and go to bed, knowing it would shut down when done.
Of course I had forgotten about this incredibly stupid dialog box. Even though it defaults to the "shutdown" option, if you don't click it during the few seconds it gives you (i.e. you've gone to sleep or left the machine unattended expecting it to shut down) then instead of shutting down it "reverts" the shutdown option and reboots instead.
What kind of feature is that? You select it expecting it to do a shutdown, but unless you're standing by the machine it doesn't. According to the "What's New" article,
Automatic computer shutdown after backup or restoration finishes. You can now perform a backup at night and go to sleep without bothering about turning off the computer - the program will do this on its own.
Except it doesn't do this on its own. You have to be there to confirm the operation within a few seconds or it "reverts" and does something else.

Update 4th April 2009: Acronis Customer Support have allowed me to change my purchase from the 2009 version to 11.0.8101 with a legit serial number. They also gave me a link to the boot CD ISO image, and it all works fine. The problems described still occur, and will probably be fixed in a future release.

Thursday, March 19, 2009

Acronis True Image Home 2009 and the progress bar from hell (Updated)

The opening boot screen of Acronis True Image Home 2009 build 9709 would be funny if it wasn't so ironic. My ability to "compute with confidence" has plummeted since I bought this product.
As part of the 2009 Defrag Shootout I have been using Acronis True Image Home v11.0.0.8027 that belongs to a friend even though I have bought my own copy of TIH 2009, because it has a nasty bug that is still not even properly acknowledged after 6 weeks.
These photos show what happens. I boot up off the CD and select "Backup". Then I choose the entire C: drive, with a sector-by-sector backup.
It must be a full backup to a new backup file on my external 400GB USB drive bought specially for this purpose.
I select High compression to reduce space. The estimated size is 54GB, but the file turned out to be 89GB, but there are a lot of ZIP and MP3 files on the disk, so that's OK I guess.
Then I ask for the backup to be verified.
The summary screen shows what has been selected, and then the fun starts.
Here are the opening progress bars. As expected, both are showing 0%
Then the remaining time estimate starts at around 30 minutes and soon drops. The "total progress" bar moves faster than the "current operation".
Eventually the "total progress" bar has hit 100%. The estimated time will remain at 13 seconds for the next 2 hours 47 minutes.
In the meantime the "current operation" moves slowly along from 12% to 100%
Nearly there after 3 hours...
Step 2 is quick, and then the verify begins. It will take 50 minutes, not 11 hours or 16 minutes.
How it guesses 1 minute and 57 seconds and then stays like that for the next 40 minutes I have no idea.
Eventually the operation completes, after 4 hours.
I originally reported this bug, along with photographs, on Monday, 2nd Feb 2009. I received a reference "Case 00062866" the same day. I sent an enquiry email on 11th Feb, and had the following rather sad chat with their online help on 12th Feb:
(Click for a bigger image).
After "only" 5 weeks I received a follow-up email, and was advised to download the same version (9709) that I used when I reported the bug. They also gave me the URL to a new .iso file (also version 9709), which I used to take these new photos. I have been told
"The time variation in progress bar might take place because of particular software/hardware configuration. There may be some applications running on the background that may have higher priority level than Acronis software."
I have pointed out that the boot CD only runs the Acronis software, and the problem occurs on different machines. I have promised to send additional photos when I do a full laptop backup this weekend.
Fortunately the backup images do work, in spite of the obviously bad programming on the display. I have never seen a beta product with such an obviously bad bug, let alone a final product. It was released before December 2008, and after 4 months it still isn't acknowledged, let alone fixed.

Update 4th April 2009: Acronis Customer Support have allowed me to change my purchase from the 2009 version to 11.0.8101 with a legit serial number. They also gave me a link to the boot CD ISO image, and it all works fine. The problems described still occur, and will probably be fixed in a future release.