I think I've got the interface working, and the test works: if(list[0] is IIndexedListItem). I'm getting an InvalidCastException when I try to cast the list: List<IIndexedListItem> newlist = (List<IIndexedListItem>)list; Instead, I tried:

List<IIndexedListItem> newlist = new List<IIndexedListItem>();
foreach(IIndexedListItem item in list)
{
newlist.Add(item);
}
newlist = newlist.OrderBy(p => p.Index).ToList();

This does what I need, so I'm back to work, I just wonder if I'm missing something easy about casting the lists.

Thanks, Ian. I'll take a look at interfaces. My second question is about controlling the order of class properties returned when reflecting. I need to see the fields themselves to set up columns into which the values will eventually be placed. I can make it work by adding a property declaration for each field, but I was wondering if there's something else available with reflection to control the order in which fields are returned. It seems to depend on inheritance order followed by position within the class declaration, but I can't find it documented so I don't want to depend on it, and in any event, the inheritance ordering messes it up for my case.

I'm trying to use reflection to generate a report from my classes. The trouble comes with class fields that are lists of other, smaller, classes that will be reported as tables. I can isolate those fields using properties ([ReportAttribute("GenerateTable")])in my class definitions, and get the next layer down with:

foreach (FieldInfo fi in FieldsThatAreLists)
{
IList list = (IList)fi.GetValue(this);

if (list[0] is MyClass)
{
List templist = ((List)list).OrderBy(mc=>mc.Index).ToList();
list = (IList)newlist;
}
else if (repeat for every possible class...)

ReportGenerate(list);
}

Since all of my (smaller) classes have a property called "Index", is it possible to eliminate the maintenance crushing if (list[0] is MyClass)... with something more elegant? And once that's done, the ReportGenerate() method needs to sort the order of things in each class to get the report columns straight. I'm working on doing this with more properties in each class definition, but is there a simpler way?

I'd go with encoded pulses. That makes it more like a TV remote.

I agree. But you wouldn't want any of my ideas. Instead, find your own. In today's CodeProject Daily News email, there's a link to an article about "10 Sharepoint Deployment Challenges". Fix one of them so that there are only 9. Or, if Sharepoint doesn't appeal to you, read another article with a list of 10 problems and fix one. Don't trust articles listing less than 10 problems because any worthwhile list has 10 items, and fewer is an indication that the easy ones have been fixed.

Who goes 400 pages deep (as of today) into a forum just to rub it in? :sigh:

Thank you. I'll put up a big sign on my desk with "is" and "as" and ToString() so I don't have to ask this again.

I'm trying to find a cleaner way to reflectively get at the contents of my class that are lists of other classes:

class BigClass
{
public List<LittleClass1> LittleList1;
public List<LittleClass2> LittleList2;
public string BigString;
}

class LittleClass1
{
public string a;
public int b;
}

class LittleClass2 : LittleClass1
{
public string c;
}

To look into BigClass I use

foreach (FieldInfo fi in BigClass.GetFields())
{
if (fi.GetValue(bigClassInstance).ToString().StartsWith("System.Collections.Generic.List"))
{
//must be a list
}
}

It finds the lists, and I can process them from there, but there must be a better way.

It's hard to tell where your 15 choices come from, but I recently had a similar problem. If you're choices are based on a reasonably designed class or classes, you should look at using reflection to dynamically add the controls you need:

foreach (Type mytype in Assembly.GetEntryAssembly().GetTypes())
{
if (type_matches_criteria)
{
(create new control)
(adjust control details and location)
Controls.Add(new_control)
}
}

Then to use your controls:

foreach (Control ctrl in (from Control c in Controls where c (meets criteria) select c))
{
if (ctrl.Checked) // or whatever
{
ctrl.Text = "Blah";
}
}

Thanks! I think is works for the code I've got today, but you probably saved me from myself on some future project. Molly

PIEBALDconsult wrote:

Or perhaps SetDevice should handle determining which type of device it was passed.

Wouldn't that mean creating a big SetDevice to handle all types, and just move the same code into SetDevice? Even if the code is a little less ugly thanks to is. Molly

I have a form with device information for for each type of device. Most of the information is similar, so I'm sharing a single form, using SetDevice() to setup fields and controls specific to each derived device type. (right now, all SetDevice methods are inside the form, not the Device classes). SelectedDevice is instantiated as a Device, then cast to whichever derived class is appropriate. The cast is necessary because at compile-time, SelectedDevice is just a Device, but at run-time will have a specific derived type.

My apologies for using the term 'abstract' a little too loosely. The SetDevice methods control display within a form, and are not part of the Device class. I started with SetDevice(SelectedDevice); but the compiler kicks that back because it can't be resolved at compile time. Molly

I know I'm missing something simple. I have a base class, Device, and a bunch of derived classes Dev1, Dev2... Depending on the type of device active at the moment, I have an abstract method for each derived type. Deciding which to use leads me to:

if (SelectedDevice.GetType() == typeof(Dev1))
{
SetDevice((Dev1)SelectedDevice);
}
else if (SelectedDevice.GetType() == typeof(Dev2))
{
SetDevice((Dev2)SelectedDevice);
}
else if ...

It works, but it just feels ugly. Molly