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 ;)