Generics Problems

Kevin Marois

yes, but I still wont have access to the properties, at least without doing

Type type = typeof(T);
var prop = type.GetProperty("Name");
prop.SetValue(entity, "TheName", null);

not sure I like this because the property names would have to be listed in calls to GetProperty. I dunno, what do you think?

If it's not broken, fix it until it is

Clifford Nelson

OK What you need to do is create and interface:

public interface IEntity
{
string SomeProperty { get; set; }
string Caption { get; set; }
}

Then use this interface on the classes:

public class Entity1 : IEntity
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2 : IEntity
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}

Then use is in the generic:

public partial class Form1<T> : Form where T : IEntity, new()
{
T entity;

public Form1()
{
    InitializeComponent();
    entity = new T();
}

}

Kevin Marois

Can't use an interface because most of this code is already in place. Have to work with what I have. However, I think this will do it:

public partial class Form1 : Form
{
T DataItem;
Type type = typeof(T);

public Form1()
{
    InitializeComponent();

    var DistrictId = 10;
    DataItem = (T)Activator.CreateInstance(typeof(T), DistrictId);

    setProperty("Name", "The Name");
    setProperty("LinkedToBilling", true);
    setProperty("BillingStartDate", new DateTime(2012, 01, 15));
}

private void setProperty(string PropertyName, T Value)
{
    var prop = DataItem.GetType().GetProperty(PropertyName);

    if (prop != null)
    {
        type.GetProperty(PropertyName).SetValue(DataItem, Value, null);
    }
}

}

This will allow me to attempt to set a property. Remember that in this case most of the properties exist on both objects. But this code allows me to not have multiple IF blocks. I think it's clean, and it solved the issue.

If it's not broken, fix it until it is

Ennis Ray Lynch Jr

Why bother with generics if you can't use them? You are better off doing things in a straight forward manner twice, than once in a non-obvious manner.

setProperty("Name", "The Name");
setProperty("LinkedToBilling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));

May look like a nice, elegant solution, until you realize that

setProperty("Name", "The Name");
setProperty("LinkedToBiling", true);
setProperty("BillingStartDate", new DateTime(2012, 01, 15));

doesn't give a compiler error.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

Kevin Marois

Ennis Ray Lynch, Jr. wrote:

doesn't give a compiler error.

Exactly. If a property doesn't exist, then I don't want a compiler error.

If it's not broken, fix it until it is

Ennis Ray Lynch Jr

I am going to have to go out on a limb here and say that yes you do. If you don't then you probably need to reconsider your approach. You are refactoring code here, refactoring implies, improving, not reducing lines of code, increasing complexity, or reducing maintainability. This fails the smell test. If you can't add improvement, don't refactor.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

Kevin Marois

It solves what I'm trying to accomplish. Lines of code, prettyiness, ect, are not the prime concern. I'm trying to make a form work for more than one entity. Added multiple block of duplpicate code is exactly what I DON'T want. Having said that, do you have an alternate solution?

If it's not broken, fix it until it is

Clifford Nelson

You can also define something a dynamic, thus solve the problem. Also, you "should" go back and fix the code as just good coding practice. All you have to do is define the interface, and then find all classes that work with the form and add the interface. It will inprove preformace since eliminate need to use reflection.

PIEBALDconsult

If the classes aren't common enough then you can't. And I'd pass an instance into the Form's constructor if I could.

public interface IX { ... }
public class X0 : IX { ... }
public class X1 : IX { ... }

public class MyForm
{
private IX x ;
public MyForm ( IX X ) { ... }
}

IX x = new X0 ( ... ) ;
MyForm f = new MyForm ( x ) ;

Ennis Ray Lynch Jr

I wouldn't use it but you can use the wrapper pattern below. It isn't elegant, but is a way to handle what you want without changing the underlying objects using interfaces, which really is probably the best solution.

public class Wrapper{
private Object mObject;
public string Name{
get{
string result = null;
if(mObject is SomeTypeIRecognize){
result = ((SomeTypeIRecognize)mObject).Name;
}
return result;

    }
}

public Wrapper(object o){mObject = o;}

}

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

Clifford Nelson

I have to agree. There appears to be no reason to use generics.

Lost User

Right-click the "Caption" property, choose "Refactor / Rename"?

Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]

jschell

Kevin Marois wrote:

so the guy who wrote them decided to duplicate the forms instead of making one form that works for both. So I'm refactoring them.

Obviously a good decision by that person because they are in fact different. The fact that there seem to be common components between them is NOT sufficient reason to assume that they are the same. As an example the fact that Word and Visual Studio both allow me to type text doesn't mean that those two code bases should be merged.

Kevin Marois wrote:

What is the right way to work with this object?

The right way is to re-assess the decision to combine them in the first place. Nothing you have posted here suggests that they should be combined. And in fact what has been posted would suggest that they should NOT be combined. Of course maybe there is some other factor that makes it obvious.

Kevin Marois

jschell wrote:

Obviously a good decision by that person because they are in fact different.

The fact that there seem to be common components between them is NOT sufficient reason to assume that they are the same. As an example the fact that Word and Visual Studio both allow me to type text doesn't mean that those two code bases should be merged.

This is an entirely stupid argument. You're saying it's ok to have 2 entirely duplicate forms and their code becuase the data they work with is different.

jschell wrote:

The right way is to re-assess the decision to combine them in the first place. Nothing you have posted here suggests that they should be combined. And in fact what has been posted would suggest that they should NOT be combined.

Again, same form, same code, different data - There is NO good reason to have 2 identical forms.

If it's not broken, fix it until it is

Kevin Marois

That is exaclty what I'm trying to avoid - lots of IF blocks all over the place. The generic & reflection code I posted will work fine.

If it's not broken, fix it until it is

Kevin Marois

Um, whaaa?

If it's not broken, fix it until it is

Lost User

public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}

Looks like the same two classes to me. What did I miss?

Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]

Kevin Marois

You missed that these are data entites that are both passed to the same form. The code in the forms is identical, except where the data is concerned. There's no good reason to have 2 forms.

If it's not broken, fix it until it is

Lost User

I see. And you need to set them only once? I mean, you could expose two properties on the form, used to set the data. If the code treats them as being identical, then why not assign those two strings?

Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]

dbaseman

The best way to do this is to create an interface that encapsulates the common properties of your entities:

public interface IEntity
{
string SomeProperty { get; set; }
}

public interface IAnotherInterface
{
string Name { get; set; }
}

Each entity can inherit multiple interfaces, depending on how you want it set up:

public class Entity1 : IEntity, IAnotherInterface
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}

If every entity has a certain interface, then you can require it in the Form definition:

public partial class Form1 : Form
where T : IEntity

Finally, cast to the interfaces to set properties. If only some entities implement a given interface, check first.

void SetSomeProperties()
{
(entity as IEntity).SomeProperty = "foo";
if (entity is IAnotherInterface)
{
(entity as IAnotherInterface).Name = "bar";
}
}