Here’s a head scratcher for the programmers in the bunch:

In this code fragment, assume pt is a valid integer pointing at an “=” sign in StringToBreak, and Comparison(i) is “=”


If pt > 0 Then
  PostCompare = Trim(Mid(StringToBreak, pt + Len(Comparison(i))))
  PreCompare = Trim(Left(StringToBreak, pt - 1))
  CompareType = i

  Exit For
End If

You’ll notice that I assign PostCompare before PreCompare in this fragment. Usually, I assign such things Pre then Post. However, I found that if I had the PreCompare *before* the PostCompare line, where it was originally, then PostCompare was always “”, an empty string. Making no other changes at all, other than swapping the order of the PostCompare and PreCompare lines as you see above, suddenly things were working again correctly, and providing the expected results. Bwah? I hope there aren’t more cases like this, because if Left() is setting the string it’s working on to the result, lots of badness will result (although that doesn’t generally seem to be the case).

And that’s not even the worst of what I encountered this week. The other day, I spent hours trying to figure out why my custom sorted item collection was acting exactly like a normal collection, instead of what it was supposed to do. Worse, it was working correctly for ItemsByType (each of which is an object in an element of another collection), but not for the full mixed-Items collection with all the stuff in it. Boggled. I finally just removed “Implements IEnumerable” and bam! suddenly it was working correctly everywhere.

Sometimes, programming is very annoying.