As per usual these days, I’m not prompt on this update.
Back on December 23, 2012, GCA hit 5602 downloads at e23. And on December 31, 2012, the user rating climbed to 4.30, which was a nice way to end the year.
As per usual these days, I’m not prompt on this update.
Back on December 23, 2012, GCA hit 5602 downloads at e23. And on December 31, 2012, the user rating climbed to 4.30, which was a nice way to end the year.
Back on September 23, 2012, GCA hit 5501 downloads at e23.
On July 21, 2012, GCA hit 5401 downloads at e23.
On May 12, 2012, GCA hit 5300 downloads at e23.
On March 19, 2012, GCA hit 5201 downloads at e23.
And, since I forgot it at the time: back on January 22, 2012, GCA hit 5101 downloads at e23.
I figured out the problem with the routine/variables in the previous post. The issue was that StringToBreak was being passed as ByRef when it didn’t need to be. Changing it back to ByVal fixed things.
Basically, the calling routine was passing the same variable to StringToBreak and PreCompare. Because both were ByRef, this made those two variables actually aliases to the same memory location, and assigning PreCompare the results of Left() also made StringToBreak appear truncated.
Mystery solved.
Still no idea on the weirdness related to my custom collection becoming a normal collection when using Implements IEnumerable.
Armin
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.
Happy turkey day, everyone!
On November 20, 2011, GCA crossed 5000 downloads at e23! Woo hoo!
Last month, on September 17, 2011, GCA hit 4900 downloads at e23.