Arduino, cars, electronics and more…
I have just released the latest version of RibbonVu.
One of the things I rather like is the ability to extract images from PDF documents without having a PDF reader installed on the PC. That’s just the tip of the iceberg though – head on over to RibbonVu to find out more.
Over the past few years the popularity of multiple monitors has taken off thanks to cheaper and more powerful hardware becoming available. One thing I have noticed though is that a lot of programs either don’t support multiple monitors, or support them incorrectly.
For example, I was checking out a competitors product recently (who shall remain nameless) and discovered while trying to run a slide show that there was no option that asked me which monitor I wanted to display the slideshow on. This would have been quite an inconvenience if I wanted to display a slideshow on a projector conencted to my PC while keeping the other monitor private. Another example which I’ve seen all too many times is windows that appear half off the screen.
This problem stems from the fact that I’m currently running two monitors, but the primary monitor is on the right and the secondary is on the left. This means that the left most pixel is not zero as some people may think it is but -1920. The same could apply for the topmost pixel if I had another monitor connected (that wasn’t my primary monitor) on top of the other monitors. The result is that the dialog appears on the right hand side of the monitor with half of the dialog cut off.
When I was writing one of my first programs many years ago, I fell into this “trap”, but luckily I was able to pick it up before the program was released due to the above-mentioned setup. The solution is quite simple: instead of writing…
Left = (All Screens Width - Width) / 2;
…or to that effect, you should use…
Left = (Primary Screen Width - Width) / 2;
I’ve seen similar bugs in programs that have been released as OEM software. This is just a basic (and probably not the best) example to show you that it’s quite easy to introduce a bug into your program without you even realizing it, and that it could happen to anyone.
I was having a bit of a ponder this morning about what I was taught during the brief time I went to TAFE to learn programming. I recall that the instructor was explaining that it doesn’t matter how you write a program because modern computers are quite powerful and can much through code like it’s nothing else. This got me thinking though, what if I needed to execute the code I’d just written millions of times? With the advent of high definition video and hard drives in the Terabytes, the ability to crunch large amounts of data is becoming more and more commonplace.
A prime example of this came to me while I was testing the PDF extract feature of the latest version of RibbonVu. I loaded a 75 page document and it worked fine, so then I went into sadistic mode and loaded a 2,000 page PDF file into memory just to see what would happen. I sat there an watched the program scan through the 2,000 odd pages of PDF goodness and noticed the task manager memory usage was climbing fast until *crash*, I got an out of memory error. After looking at the code a bit I discovered that for each image that was being extracted, data was being loaded into memory two or three times, not good. After a bit of code tweaking I was able to get the code working by writing the image data only once and set off to extract another 2,000 pages of images. This time it worked a charm, no errors and a third of the memory usage. It even ran quicker.
I guess what the instructor taught me that day could be relevant to things that don’t need to be iterated, but I am of the opinion that this may encourage people to become complacent and write inefficient code. I guess you could compare writing code to building a car – the more weight you add, the slower it’s going to go. That’s not to say that you should not do error checking or input validation (or other things like that), to do so would be like removing the safety features of your car just so you can go faster – it aint gonna end pretty.
A number of improvements have been made to RibbonVu since its first release a few weeks ago. Among the new features are Windows Image Acquisition (WIA) camera support, contact sheets and PDF image extraction and more. Most importanly, RibbonVu now works on Windows XP and Vista in what we call RibbonVu Compatibiltiy Mode.
If you’re interested in a free copy of RibbonVu Professional when it comes out head on over to the RibbonVu web site, download the latest beta version and tell us what you think by completing our short survey. Over the coming months when the new version is released you will be sent details on how to register your copy of RibbonVu Professional.
The inaugural version of RibbonVu for Windows 7 is now available. Check it out here.
Things are starting to look normal around here again. All the zip files (such as the Arduino libraries, etc…) should be back up in the next few minutes.
I’ve just moved servers within my host and things appear to have gone a bit pear shaped. Things should be normal soon (I hope).
Jonathan
Wow, how the time flies. A couple of months ago I decided to dust off some code I was working on many moons ago and see if I could turn it into something worthwhile. The result is my latest creation – RibbonVu.
At the moment it will only run on Windows 7 as it uses the Ribbon Framework by Microsoft. There are plan for a “compatibility mode” which will allow RibbonVu to run on Windows XP or Vista (although it won’t look as pretty).
I’m getting to the stage where the first beta version is almost ready for release. The final version will be released as shareware, but the beta versions will be unrestricted and set to expire on a certain date (just like Windows 7).
The RibbonVu web site – ribbonvu.net – has more details so head on over there if you want to find out more or become a beta tester.
I decided to bite the bullet and go with the new shell option for Project Sigma. I found a reasonably straight GK Super Saloon in Melbourne (and I’m in Canberra) on eBay. There is a small amount of rust in a few places – which is typical for a Sigma that age – but I’ll just swap the rusty parts off the old car.
The guy said that the car hasn’t been registered in 5 years, but it should be drivable, so I decided to get a permit and drive it home. We set off just after sunrise and got to north Tasmania..er..the Mornington Peninsula at about 2PM. After leaving Melbourne a little later than anticipated we got home with half a hour left before the permit ran out without any major problems. The engine ran quite smooth and everything did what it was supposed to do – although it could do with better headlights, but they did the job.
I was quite happy with the purchase as the “new” car has decent tyres, which I would have had to fork out more than half the price that I paid for new ones. Now it’s just a matter of me transferring all the stuff I want off the old car onto the new one and getting it registered. Later I’ll post some pics, but for now it’s time to go back to bed…
Well, I’m finally back after a long trip to France (at least it was work funded). Had a nice relaxing Easter with the family and close friends and managed to catch up on some sleep, so now I can get back into the swing of things.
I have been discussing the situation of my GK Sigma with a number of people, both online and in “real life”, and am debating on whether or not to start afresh with a new shell or take the current shell I have to a smash repairer to get it straightened out. I’m starting to lean more towards the new shell option as it will save me the trouble of converting the gearbox to manual and only a few other things will need to be changed over.
If I see something I like over the next couple of weeks, I’ll go ahead and buy it, otherwise I might have to stick with the straightening option. Meanwhile here are a couple of pics that show the extent of the damage:
Passenger side bonnet "alignment"
Drivers side bonnet
