Monday, October 31, 2005

Dear Mr. Vick

I wanted to lend some support to a great idea I heard from Paul Vick on .NET Rocks!

"Heard you on .NET Rocks! mention the possibility of doing away with VB's line continuation character - presumably making it more C-like in its treatment of whitespace. I think this would be GREAT!

"I have come to VB from a long history of C and C++ and (especially with VB.NET) the only think that has really niggled is VB's line-oriented parser.

"I expect you'll have to pull off some pretty neat tricks with context-sensitive parsing but please, please please do it!"

Friday, October 28, 2005

SQL Surprise

Got tripped up by this little bit of SQL (which I naively bashed out in Query Analyzer):

select * from Addresses where AddrID in
(select AddrID from BankAccounts where BankID=234255)

The BankAccounts table includes a foreign key to Addresses, giving the address of the branch at which the account is held (there is no intermediate BankBranches table). So I was expecting this query to give me one row from Addresses (or perhaps none). In fact, it gave me the whole damn table.

The problem is that the BankAccounts table doesn't have an AddrID column; it's called BankAddrID. So why didn't the query give an error? I'm no SQL expert but basically it's because the outer select is in scope (which allows correlated subqueries to work) so the query I wrote was effectively:

select AddrID from Addresses
cross join BankAccounts
where BankID=234255


Thursday, September 15, 2005

Philosophical Development

Nice rant from Roy Osherove. The esoteric work is necessary up front to make the whole thing hang together properly, and you should be able to drill down into it if you find that useful or interesting, but it shouldn't pollute the mainstream information. What we need there are more problem-focussed discussions and less BS!

Wednesday, August 03, 2005

Combo Box Caching

Got tripped up the other day by an elementary piece of behaviour that I expect everybody
knows about except me (and the rest of my team). What do you think you will see
when you drop down the combo box in the following app?

Public Class Form1

Protected Overrides Sub OnLoad(ByVal e As EventArgs)


Dim c As New C("Marco")


c.Value = "Polo"

End Sub

End Class

Public Class C

Public Sub New(ByVal val As String)

Value = val

End Sub

Public Overrides Function
ToString() As String


End Function

Value As String

End Class

Well the title of this post gives it away; of course you see "Marco". The combo box caches the ToString results when the items are added. I have yet to find a way to tell it to update its cached strings, without removing and readding items.

I love the fact that you add objects to combos and other lists, but this behaviour just shows it up as something of a hack: we might as well still be storing strings and putting the object reference in ItemData.

This happens in VS.NET 2003 and 2005. My friends tell me Java has a much more sophisticated model with paging and everything. Come on Microsoft, time to catch up!

Monday, July 25, 2005

What's on HDTV?

Could this be the definitive blog on HDTV? I haven't read it all yet, but it looks like it deserves to be read all the way through from the beginning.

Sunday, July 24, 2005

VSTS Part 2

Well, carrying on with the course after the last rant, we come to a useful diagram that shows how the three editions and the "Foundation Server" fit together.

Visual Studio Team System diagram

Visual Studio Team System

With eager anticipation of at last being able to do "proper" development without having to scrounge empty fag (that's "cigarette", for younger or non-English readers) packets off of my smoker friends, I hereby embark on a study of VSTS by studying the (currently) free Microsoft Visual Studio 2005 e-learning courses beginning with Clinic 2551: Introduction to Visual Studio Team System.

Well, we're not off to a good start. Here is the modern take on the software development lifecycle (SDLC) according to MS:
  • Envisioning (output: scope document)

  • Planning (approved plan)

  • Development (tested code)

  • Stabilizing (approved for release)

  • Deploying (productive users)

The output from "deploying" is mine. The course merely says it marks the end of the cycle.

But the big worry for me is where is design? In a "normal" development team, the majority of developers are actually coders and anyway, the output from the development stage is "tested code"; no mention of architecture or design documentation. So design isn't part of the development stage. And we certainly can't expect it to come out of the planning stage.

VS2005 includes a "Team Architect" edition, so the activity hasn't been actually lost, but to exclude it from such a high level view, with no separate output, well, MS might as well come right out and formally declare it to be "deprecated".


You couldn't wish for a simpler tool: just stuff a conditional test in your code to document what should be true at that point, and the debug build of your app will throw up a message if you (well, obviously not you; some other developer) got it wrong and didn't satisfy the precondition or screwed up some data somewhere.

But what should your code do if the assert is untrue in the release build? Well, you say, that shouldn't happen because your testing will have uncovered all the bugs that would lead to the assert failing. Hah!

In the best traditions of defensive programming, what you should really do is abort at least that operation by throwing an exception. But if you're going to do that, why bother with the assert in the first place?

The only justification I can think of that isn't pure "my code ain't got bugs" optimism (and if you're that kind of programmer you won't be bothering with asserts), is that you're sure that testing is going to exercise the dubious condition and you really can't afford the enormous time and space penalties of the if not condition then throw exception statement.

Don't get me wrong, I love Debug.Assert; it's a neat way of expressing pre- and post-conditions. But too often after writing one I get this nagging feeling that I haven't done enough to make my code "good". Perhaps what I need is a Release.Assert statement instead.

Monday, June 13, 2005

Upgrading to Whidbey Beta 2

Here is an ongoing list of issues encountered during a trial upgrade of our VB.NET app to Visual Studio.NET 2005 Beta 2. These are still very early days, so I expect more to come out of the woodwork, but at least our solution loads into this version—Beta 1 upgraded the projects and then complained that they were corrupt!

Use of Object as a switch statement selector

The programmer forgot to typecast an Object instance (retrieved from a database) before using it in a switch statement. This works in 2003 but not in 2005. You get the following error: "Error 133 Option Strict On disallows operands of type Object for operator '='. Use the 'Is' operator to test for object identity."

As it says, Option Strict must be on for this to show up (annoyingly the installation default is still Off). Example:

Private Sub Test()

Dim colour As Object = Color.Red

Select Case colour 'Needs to be CType'd otherwise...

Case Color.Red 'Error here,

Case Color.White 'here,

Case Color.Blue 'and here.

End Select

End Sub

Inconsistent DLL References

Some of the projects in our solution referred to one particular DLL (FarPoint Spread) in the GAC while other projects referred to it in the programs folder (the same assembly version was begin referred to in all cases). At least this was the situation after the solution was upgraded. Whidbey complained about this when VS2003 never had.

Invalid Type Casts

In a couple of places in the code the developer had coded a DirectCast that was never going to work. This must have been in dead code because we never discovered it in testing (or production). VB 2005 has better compile-time type checking and picked up on these errors.

Decrypting a 0-Length Buffer

CryptoStream.Close threw if it was asked to decrypt a 0-length stream. This just worked in VS2003.

SqlCommand.Parameters.Add(String, Object) Obsoleted

This overload has been obsoleted because it can lead to ambiguous calls. AddWithValue should be used instead. I found more info here.

ArrayList.IndexOf Behaviour Change

In VS2003, a call to ArrayList.IndexOf(x) would call x.Equals(item) for each item in the list. In Whidbey, it calls item.Equals(x) for each item instead. This broke our app because we hadn't observed the Object.Equals override requirement that x.Equals(y) returns the same value as y.Equals(x). I have raised this as a compatibility bug at the MSDN Product Feedback Centre. (Update: the new behaviour will remain.)

Accessing Controls from the Wrong Thread

I knew that you should only access a control from the thread that created it, but we've been getting away with setting label text directly from a worker thread (until now).

P.S. Thanks to JFo for more info on this, i.e. you can set Control.CheckForIllegalCrossThreadCalls to False to bypass this check (if you're feeling naughty).

A Googol Warning Messages

Well, perhaps not quite that many, but there sure are a lot. I'm just beginning to sort through them.