|
jrahma wrote: I want to know how can I display a live TV in the same application within a panel or a component so it will be part of the screen?
There's no "TV-control" in .NET. How did you plan on getting the TV-information in Windows?
I've had a Pinnacle-TV card and that came with an application to operate it (and record to harddisk). If you have a similar app, you could use an old trick[^], I believe you used that one before.
Best would be to "search" on the COM-tabpage from the "Add References" dialog in Visual Studio. Most of those apps use a COM-component to display their stuff, and it might be easy to re-use it.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Has anyone done this? I've tried using wmi via c sharp with the namespace
\\[servername]\ROOT\cimv2\dell:Dell_RemoteAccessServicePort and haven't gotten anywhere.
Our drac IP list is not accurate and I'd like to have a program that queries a server list and gives an update list from WMI or some other source. I've seen racadm do it locally, so it must be stored somewhere that is accessible from the OS.
I just did a procmon on racadm and could not find anything as far as how it generates the drac ip when it does a query. Thanks for reading.
modified 7-Sep-12 16:38pm.
|
|
|
|
|
I'm refactoring a WinForms project. I have 2 forms that do the same thing, except the data entities passed in are slightly different, 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.
Assume I have these 2 entites:
public class Entity1
{
public string SomeProperty { get; set; }
public string Name { get; set; }
}
public class Entity2
{
public string SomeProperty { get; set; }
public string Caption { get; set; }
}
In the CTOR of the form I have:
public partial class Form1<T> : Form
{
T entity;
public Form1()
{
InitializeComponent();
entity = (T)Activator.CreateInstance(typeof(T));
}
}
The problem is I now need to set properties on the object passed in. In most cases the 2 objects have the same name properties, but ther are differences.
What is the right way to work with this object? Seems like I have no choice but to cast.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
What I think you need is:
public partial class Form1<T> : Form where T : new()
{
T entity;
public Form1()
{
InitializeComponent();
entity = new T;
}
}
|
|
|
|
|
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
|
|
|
|
|
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();
}
}
|
|
|
|
|
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<T> : Form
{
T DataItem;
Type type = typeof(T);
public Form1()
{
InitializeComponent();
var DistrictId = 10;
DataItem = (T)Activator.CreateInstance(typeof(T), DistrictId);
setProperty<string>("Name", "The Name");
setProperty<bool>("LinkedToBilling", true);
setProperty<DateTime>("BillingStartDate", new DateTime(2012, 01, 15));
}
private void setProperty<T>(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
|
|
|
|
|
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<string>("Name", "The Name");
setProperty<bool>("LinkedToBilling", true);
setProperty<DateTime>("BillingStartDate", new DateTime(2012, 01, 15));
May look like a nice, elegant solution, until you realize that
setProperty<string>("Name", "The Name");
setProperty<bool>("LinkedToBiling", true);
setProperty<DateTime>("BillingStartDate", new DateTime(2012, 01, 15));
doesn't give a compiler error.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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;}
}
|
|
|
|
|
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
|
|
|
|
|
I have to agree. There appears to be no reason to use generics.
|
|
|
|
|
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.
|
|
|
|
|
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 ) ;
|
|
|
|
|
Right-click the "Caption" property, choose "Refactor / Rename"?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Um, whaaa?
If it's not broken, fix it until it is
|
|
|
|
|
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
if you can't read my code, try converting it here[^]
|
|
|
|
|
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
|
|
|
|
|
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
if you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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 wrote: This is an entirely stupid argument.
Nope. I have seen countless attempts by people to combine code based on nothing more than what they perceive as code duplication. That happens a lot with inheritance. It focuses on the duplication instead of focusing on the need.
Kevin Marois wrote: You're saying it's ok to have 2 entirely duplicate forms and their code becuase the data they work with is different
What I said was that from what you posted here that is the case.
Kevin Marois wrote: There is NO good reason to have 2 identical forms.
Actually there can be a very good reason. Because they represent two different conceptual entities. Because they are different it can mean that in the future they might go in different directions.
Again code duplication is not the sole criteria that one uses to make this decision. And I gave you a specific example which would demonstrate why one wouldn't do that.
Without more information all I can suppose is that what you really need, if indeed there is a real need at all, is a helper class. It contains the duplicated code. The current implementations would use that.
That however still supposes that there is a real need to combine this code.
|
|
|
|
|
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<t> definition:
public partial class Form1<T> : 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";
}
}
|
|
|
|