• Australian Weather Radar Gadget v1.2

    It’s been a few years since I’ve been able to update the Vista Sidebar Gadget that I wrote which displays the radar images from the Australian Bureau of Meteorology. It’s worth noting that while the sidebar doesn’t exist in Windows 7, you can still add gadgets to your desktop.

    I’m now hosting the source code on Google Code, and I’ve released a minor update to reflect some changes to radar locations:

    Added:

    • Sydney (Terry Hills)
    • Norfolk Island
    • Emerald (QLD)
    • Bairnsdale (VIC)
    • Perth (Serpantine)

    Removed:

    • East Sale

    I’ve had a few reports of a memory leak when people run the gadget for extended periods of time. I think this may be an unfortunate side-effect of the way the gadget uses HTML. Maybe re-writing the gadget using WPF or Silverlight might help with that.

    The gadget can be downloaded from the Windows Live Gallery from here (currently 1.1 but hopefully 1.2 will be approved shortly), or go to the Downloads page of the Google Code site.

  • What makes a workplace (part 1)

    Not everyone gets to work somewhere like Fog Creek, Google, Microsoft or even LobsterPot Solutions. I thought I’d take Rob’s lead and write down some of the things that come to mind when I think of the characteristics of my ideal work life. It ended up a bit longer than I was expecting so I’ve broken it up into multiple posts.

    People

    • Friendly
    • Peers
    • Complimentary skills
    • Shared values
      • Passionate about quality
      • Continuous learning/improvement

    My best work experiences have always coincided with being part of a great team. I don’t remember too many people that I’ve worked with that I haven’t got along with well. I also discovered that you can learn a lot from older, wiser colleagues – sometimes they’re in the best position to realise that the latest trend or fad is just a variation of something that’s been around before.

    Having complimentary skills is also really valuable. You can learn from each other, but also you can bring new perspectives to particular problems that otherwise may not have been considered.

    Edited 24/6/2010 - Included LP in list of desirable employers!

  • The bad old days of VBA, and opening Word from Excel

    You tend to forget how good Visual Studio has become as a development environment, until you jump back into something like writing VBA macros in Excel.

    This is pretty much a VB6 environment, but maybe it’s just my memory but I didn’t think VB6 was as bad as VBA is. Even more amazing is that if you open up Excel 2010 and click on the Visual Basic icon in the Developer tab, nothing has changed. There’s good old VBA in all its glory.

    Sure, you can use .NET with Excel, but only to write add-ins. These are installed separately, so you can’t just send a spreadsheet off to a colleague and expect it to work if they don’t also have the add-in installed. Another option would be to write a full-blown .NET application that used COM Interop to call out to Word and Excel.

    So what lead me to be messing around in VBA? The scenario involves aggregating data from a large number of spreadsheets into a single Word document. If you’re thinking this sounds like something better handled with SharePoint or an intranet web application, you’d be right. Probably the “.NET application with COM Interop” would also have been a better choice,  but for now resource constraints meant that the “improvised” solution was the best that could be done, and as a proof of concept it appears to be doing the job.

    Just to be clear, this isn’t for a LobsterPot client, rather I’m just helping out a friend. The particular problem I was asked to advise on was that the Excel VBA code was launching Word, but Word would be opened in the background. The request was to make the new Word document appear in front of Excel so that the end-user could more easily see it. Sure, they could Alt-Tab or click on the Windows task bar to bring it into focus, but anything you can do to make things easier and more obvious for users is usually a good thing.

    The original code opened Word like this:

    `

    Dim wordApplication

    Set wordApplication = CreateObject(“Word.Application”)

    `

    This works fine, but Excel (where the VBA code is running from) stays in the foreground. Adding one extra line to the code solves the problem:

    `

    Dim wordApplication

    Set wordApplication = CreateObject(“Word.Application”)

    Application.ActivateMicrosoftApp xlMicrosoftWord

    `

    The call to ActivateMicrosoftApp does the trick. One trap to be aware of is calling that method before CreateObject. That does work, but it results in 2 instances of Word opening, which is usually not desirable.