Got it! Turns out all you need to do is call the base class in your OnStyleChanged handler (or remove it the handler altogether). It's somewhat strange that the AppWizard-generated code would override OnStyleChanged but not have it call the base class.

Thanks for the reply, but this unfortunately doesn't work. Note that the AppWizard already generated code to change the style (using ModifyStyle). The appropriate style DWORD does get changed. The problem is that the ListView doesn't respond to changing the style. No matter what I change the style to, I can't effect any changes in the actual control. Any help is appreciated.

I created an app with the MFC AppWizard (in VS.net), and chose the "explorer-style project" option, which creates two panes---a TreeView on the left, and a ListView on the right. The wizard also generates a toolbar with buttons for each of the ListView styles (icon, small icon, list, and report), and the necessary code to change between the styles (via the ModifyStyle function). Unfortunately, it doesn't work. Oh, the style does get changed. I even get the OnStyleChanged notification. But the ListView doesn't change styles. (I can change the initial style in PreCreateWindow, but I want to do it dynamically.) The only changes made to the AppWizard-generated application were to add a few items to the listbox (in OnInitialUpdate): GetListCtrl().InsertColumn(0, "foo"); GetListCtrl().InsertItem(0, "aaa"); GetListCtrl().InsertItem(1, "bbb"); GetListCtrl().InsertItem(2, "ccc"); What's going on? Am I missing something really obvious? Thanks,

The VC6 IDE was written in MFC, and it was a fairly substantial app. A better example might be SourceSafe. None of the larger teams at MS use SourceSafe (partly because their code predates SourceSafe, but mostly because SourceSafe doesn't scale to hundreds of users very well).

Change the definition for F4 and Shift-F4 to use Edit.GotoNextLocation and Edit.GotoPreviousLocation. That should do what you want. They scroll through the task list if you've just done a compile, but they scroll through the find results if you just did a search.

I'm having some trouble creating an index with ADOX (against MSJet as the provider). For the life of me, I can't figure out how to make the index *unique*. Sure, there is a pIndex->PutUnique() function on the Index object, but it doesn't seem to work, since the resulting database still lists the field as "duplicates OK" when I open it in Access. I've also tried 'pIndex->Properties("Unique")->PutValue(true)', but that only results in an exception being thrown (with some unhelpful error message). But PutValue(false) doesn't result in an error. Am I missing some prerequisites for a unique index? If I change the index in Access to "no duplicates" and reopen the database, both the pIndex->GetUnique() and Properties("Unique")->GetValue() return true. Any help is much appreciated.