Something preventing default (explorer-style) CListCtrl jump to line behaviour

I'm maintaining an MFC/COM/ATL 45-odd project solution originally written with VS6. I'm now using VS2008. I'm looking at a list control(vanilla CListCtrl) which doesn't behave as we think it should. Normally in an MFC list control you can press a key, (Q say) & selection will jump down to the 1st line beginning with 'Q' (like windows explorer). Does anyone have an idea as to why this might not happen? The styles/Extended styles are set the same as another control in the same project, which DOES work OK. Do I have to send my own message, or is there a flag, etc. that controls that functionality or what? Normally Google would supply the answer, but I haven't been able to frame my query correctly to come up with the relevant info this time. Here's the line from the .rc file for the CListCtrl that doesn't jump to a line on keypress:

 CONTROL         "List1",IDC_BAL_开发者_Python百科LIST,"SysListView32",LVS_REPORT | LVS_SHOWSELALWAYS | WS_BORDER | WS_TABSTOP,0,73,493,230

And here's a line from the same .rc file showing a list control that does do that:

CONTROL         "List1",IDC_LIST1,"SysListView32",LVS_REPORT | LVS_SHOWSELALWAYS | WS_BORDER | WS_TABSTOP,1,38,501,219

As you can see, there's no obvious difference to the properties, so what program code would affect it?

I've now realised what the problem is (coming back to it after a break) - CListCtrl matches on Column ZERO(the "label" column as some have called it I think) - which is a hidden column(in this particular list control) that sometimes contains a number & sometimes is blank, so unsuprisingly doesn't do anything when an alpha key is pressed. Obvious,really - I apologise for making the problem sound more complicated that it actually was ;)