Thanks, SK...that's very clear, though I do think that having anObject[i].Increment() behave differently according to whether anObject is an array of Foo vs. List when Foo is a struct is error prone. I actually think I would prefer that array indexing behaved the same way...that is, the indexer returns a copy. Now that I've had time to sleep on it, I remember that a few years ago I fought through creating an indexer for my own particular struct and came to realize that I had no choice but to return a copy...so I was getting the exact same semantics as occurs with List. Maybe I won't fall into the same trap again in a couple of years. But I wouldn't count on it! :laugh: cheers, jim

I may be having dense programmer moment, but I just spent an hour debugging something that came down to a really unexpected (by me, at least) behavior with List<> vs. array. If you create a struct with a method that modifies a member, and invoke that method on an instance of the struct that resides within an array, the array element is modified as you would expect. But if you perform the identical operation on the struct that is contained in a List, the item in the List is NOT modified. The following program illustrates this...the effect is observable in VS 9 and 10. Does this seem correct or reasonable? It certainly doesn't adhere to one of my favorite principles of language design: the principle of least surprise! thanks, jim

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;

namespace TestByValue
{
class Program
{
static void Main(string[] args)
{
Foo[] aArray = new Foo[3];
aArray[0].Increment();

        Console.WriteLine("aArray\[0\].x is {0} and should be {1}", aArray\[0\].x, 1);
        Debug.Assert(aArray\[0\].x == 1);

        List<Foo> aList = new List<Foo>();
        aList.Add(new Foo());
        aList\[0\].Increment();

        Console.WriteLine("aList\[0\].x is {0} and should be {1}", aList\[0\].x, 1);
        Debug.Assert(aList\[0\].x == 1);      // This Assert fires
    }

    struct Foo
    {
        public int x;

        public void Increment()
        {
            x++;
        }
    }
}

}

That is correct, but transition is intransitive. So though the Foo may transition, we have no business transitioning the Foo.

Ok, I think I've done all the manifest stuff correctly. DLLGetVersion on "comctl32.dll" reports Major Version 6, Minor Version 0, Build 2900, Platform 2. Here's the actual code fragment, since at this point, I think I must be missing something blindingly obvious: LVSETINFOTIP sit; sit.cbSize = sizeof( sit ); sit.dwFlags = 0; sit.iItem = 1; sit.iSubItem = 1; sit.pszText = L"fake primary info tip"; // This works, so we know item 1 is there. CString str = m_ListCtrl.GetItemText( 1, 1 ); // This always returns false, and no info tip appears. BOOL bResult = m_ListCtrl.SetInfoTip( & sit ); The extended style includes LVS_EX_INFOTIP and LVS_EX_LABELTIP, and I've tried either, both or none with no difference in results. Any insight would be greatly appreciated! thanks, Stache

I'm trying to set up info tips for different subitems in a CListView in Report mode. I can catch the LVN_GETINFOTIP when you hover over subitem 0, and correctly display the text I want. But hovering over any other subitem doesn't produce the notify. It would seem that the method CListView::SetInfoTip might do what I want, but it fails (returns false) when I invoke it, and I have no idea why. I have an application manifest, and I am using version 6 of ComClt32.dll. I've set the extended style to include LVS_EX_INFOTIP. I'd like to get this API working. Alternatively, if there's some way to get the LVN_GETINFOTIP notify when hovering over a different sub-item, that would do it too. thanks, Stache