Dave's Blog

I just saw this on BBC Click: “Vizualize.me launched this week with a service that visualises your CV by taking the information you have put into LinkedIN and turning it into a sharable infographic.”

It was quick and easy to do and the results are quite nice, I’m not entirely sure how much use I’ll get out of it as I don’t see myself sending it to a potential employer but it did remind me to update my LinkedIn profile properly at least!

I was recently working on a bug found in our software options dialogue, well more of a suggestion really, which involved an interesting fix that I thought I’d share: The problem was that I’d used a Tree View control to display a list of options that the user could check/uncheck, I’d sorted them into sections using Parent and Child nodes and enabled the .CheckBoxes = True This was great and did the job, but I didn’t want the check boxes on the parent nodes, just on the child nodes.

The solution was to use the owner draw functionality exposed by the control to customize the drawing of the root tree nodes and prevent the check boxes from drawing, I’ve also set .ShowLines = False as they didn’t look very good without the checkboxes:

Node.Level 0 Nodes are now Owner-drawn

In order to do this you need to set the .DrawMode property to either .OwnerDrawAll or .OwnerDrawText then handle the DrawNode() event of the control, here’s the code I wrote to handle the DrawNode event:

    Private Sub tvwAvailableFilters_DrawNode(ByVal sender As Object, ByVal e As System.Windows.Forms.DrawTreeNodeEventArgs) _
        Handles tvwAvailableFilters.DrawNode

        'Hide the check box for top level nodes by overrding the draw event and drawing manually
        If e.Node.Level = 0 Then
            'Create a brush and fill the node area
            Using newBrush As New SolidBrush(Me.tvwAvailableFilters.BackColor)
                e.Graphics.FillRectangle(newBrush, e.Node.Bounds)
            End Using

            'Override Control font to Bold and Underline headings
            With e.Node.TreeView.Font
                Dim newFont As New Font(.FontFamily, .Size, FontStyle.Bold + FontStyle.Underline, .Unit)

                'Now draw the text manually
                TextRenderer.DrawText(e.Graphics, e.Node.Text, newFont, _
                                      e.Node.Bounds, Color.Black, Color.White)
            End With

            'Tell the system not to draw the object, we've just done it
            e.DrawDefault = False
        Else
            'System should draw the object
            e.DrawDefault = True
        End If
    End Sub

My girlfriend always get’s annoyed with me when I tell her to turn things off and on again: “That’s your answer to everything!”, she grumbles, but I don’t just parrot this from a script. It’s the way I resolve 90% of all problems because this is usually the first thing I’ll try in any situation involving electronics or computers.

This morning I had cause to chuckle, as I sat on the train to work. At Waddon the train stopped for a while and the driver announced that he wasn’t able to open the doors on the train and was seeking technical help. After a 10 minute pause, he announced that it was a problem with the on-board computers and that he was going to power down the train to reset it.

The lights went off and the persistent hum of the air conditioning rattled into silence for a few minutes. I sat there in gloom and wondered if that was really going to do the trick or whether we’d all be manually overriding the doors to escape. The train once again whirred into life and slowly we could see the various systems come back to life. The displays on the train train all announced that this was an Electrostar model then started displaying normal information.

So there you go, take a leaf out of my book, next time you have a problem, try turning it off and on again. You never know

Tom, one of the developers here has been working on some Silverlight stuff recently and has just hit the most amusing error message we’ve seen, I thought I’d share :

It’s quite appropriate for Monday when most of us feel like zombies

Normally when declaring variables in a programming language there are certain reserved keywords that can’t be used as variable names because they are part of the language syntax. This never really caused a problem when I was coding Amstrad BASIC as a teenager, but as language complexity increased, the amount of reserved words can start to get irksome. In fact one of the little mentioned advantages of using Hungarian Notation in variable naming was not needing to worry about hitting any reserved words. e.g

sData
iType
dDate

These days .Net standards seem to be moving away from Hungarian, or at least there are very vocal advocates for doing so, this has lead me back down the path of hitting reserved words again.

Well it turns out that there’s a solution that’s been around forever and I’ve only just stumbled across it. Closing something in square brackets in VB will allow you to escape the reserved word, following the same standard you see in SQL Server.

So now I can say :

Dim [Type] as String

or

Dim [Object] as Integer

all without the compiler exploding. Great eh? Well, I’m not so sure really. Whilst this is a nice little work around that I might use once in a while, I think that overuse could turn your code into a maintenance nightmare. If you’re trying to debug a Sub or Function, the first thing you need to do read it and understand what it’s doing, by making your code less readable and more difficult for another programmer to intuit, you’re reducing the maintainability of your code. And it’s not just another programmer you need to worry about, let’s face it, it’s probably going to be you sitting there 12 months later, wondering WTF you were thinking when you wrote the code. Here’s an extreme :

    Public Sub Main()
        Dim [Dim], [If], [Then], [Next], [For], [Public] As Integer

        For [Then] = 0 To [If] Step +[For]
            If [If] > [Public] Then
                [Next] = [If] + [Then]
                [Dim] = [Then]
            End If
        Next [Then]
    End Sub

Great for code obfuscation, not so good for making your own life easier. In fact, I wonder how the .Net Reflector would deal with the above? Not very well it seems :

Public Sub Main()
    Dim For As Integer
    Dim If As Integer
    Dim VB$t_i4$L1 As Integer = [For]
    Dim VB$t_i4$L0 As Integer = [If]
    Dim Then As Integer = 0
    Do While (((VB$t_i4$L1 >> &H1F) Xor [Then]) <= ((VB$t_i4$L1 >> &H1F) Xor VB$t_i4$L0))
        Dim Public As Integer
        If ([If] > [Public]) Then
            Dim Next As Integer = ([If] + [Then])
            Dim Dim As Integer = [Then]
        End If
        [Then] = ([Then] + VB$t_i4$L1)
    Loop
End Sub

Well there you go, if you want to write an Obfuscation program, reserved words are the way to do it. But let’s face it, I really don’t see myself using this very often. I might define the odd variable [Type] for my classes but that’s probably going too far when ‘MyClassType’ would work just as well for naming.