We’re off to New Zealand for three weeks touring the South Island. In my last-minute rush, one thing that occurred might be worth trying is to take a cheap headless GPS receiver to use with the Nokia Maps application on my 6120 Classic. A few minute searching disclosed that I can download the maps in advance (12MB for NZ, 107.4MB for Australia, guess they didn’t think people might just want one state of Australia).
So I grabbed the Maps Downloader v2 application, installed it on my Vista 64 box, followed the splash screen instructions to connect my phone and…..
waiting for device
Quite an attractive GUI, you understand, with enough subtle animation to make me think it hasn’t actually frozen yet not annoy. Someone spent some time on the appearance, the text is readable and there was an option to skip the warning splash screen in future and it is still waiting for the bloody device that is plainly physically connected and showing up in Nokia PC Suite as connected!
You see the license plate on the car in front is Z Painter and immediately think hmmm, back to front rendering.
I’ve been doing a huge amount of work recently porting the C++ OOFILE report writer to REALbasic as a complete transliteration, having given up on the earlier report-writer I was writing from scratch.
I’m using REALbasic 2008r4.1 and finding it extremely flaky when debugging. I finally worked out the cause and it’s an interesting trap.
OOFILE was written about 15 – 10 years ago and makes use of lots of inline and non-virtual functions for high-performance in C++. Methods in REALbasic are, of course, all virtual but it also has Computed Properties which allow you to write code as getter and setter functions. These are non-virtual and therefore (presumably) much faster – an ideal and idiomatic match for the inline getters and setters used heavily in OOFILE.
However, there’s one very big gotcha – if you look at an object in the REALbasic debugger, all its getters on computed properties are executed.
I have added a project at Google Code to host RB2Doxy in case anyone is interested in a solution to help document their REALbasic code. Currently it’s a bit limited in that it requires all your source to be in a single XML file and doesn’t process anything inside methods, just the class and method declarations. It may also appeal as an example of moderately complex XSLT processing.