Develop Reference

How to update class code to make it Type Independent

Problem: I currently have a class that takes in an object of type Control and does some work. I'm attempting to create a class that can take in either a Control, Button or a Label object. I can make this work however it would involve that I copy and paste the class two more times. One to work with Buttons and another to work with Labels. The logic and the members being called are exactly the same with the exception of the Type. I have simplified the concept I'm wishing to convey below:
// This class currently only does work on a Control object
public class takeControlType
{
public takeControlType(Control control)
{
string objectName = control.Name.ToString();
}
}
I could copy paste the code above and make it work by overloading the class Constructor like this:
public class takeAnyType
{
public takeAnyType(Control control)
{
string objectName = control.Name.ToString();
}
public takeAnyType(Button button)
{
string objectName = button.Name.ToString();
}
public takeAnyType(Label label)
{
string objectName = label.Name.ToString();
}
}
Am I correct in thinking that this just seems like a drag in productivity? I'm hoping I can reuse the same logic despite the Type being different as the only item that I would need to replace is the Type. The logic and properties being implemented in my class are exactly the same for Controls, Buttons and Labels. I've researched generics but due to the fact that I'm pulling back properties and methods specific to either a Control, Button or Label I can't seem to get generics to work with the object properties such as .Name or .Width or .Capture for example. The only methods the generic Type provides me with are
Equals()
GetHashCode()
GetType()
ToString()
I need access to a few of the properties I mentioned previously. How does one accomplish this in order that I might avoid having to copy/paste 266 lines of code that make up my class that currently is only able to work with Control objects?
Aside from attempting to make use of Generics I also tried to see if I could use base class type object as opposed to Control but that led me to the same issue I'm currently having with Generics. I no longer have access to the members that are associated with Controls, Buttons and Labels.
To clear up any confusion the example (non-working) code below is what I'm attempting to accomplish.
public class takeAnyType
{
public takeAnyType(anyType obj)
{
string objectName = obj.Name.ToString();
obj.Cursor = Cursors.SizeNESW;
obj.Capture = true;
obj.Width = 20;
obj.Top = 100;
}
}

Button and Label classes inherit from Control (indirectly). This means that if you only create a class for Control, you can still use it for objects of type Button or Label. You don't have to create special classes for those.
In C# (and OO languages in general), you can assign an instance of a derived class to a variable of a super class. For example, this is valid C# code:
Control control = new Button();

An answer addresses your example, but your problem seems to describe something more - doing some more convoluted login on Labels and Buttons. One way to do this is the following:
1) declare a base class to handle common issue (e.g. your name example)
2) declare a class for each Label and Button to handle specific logic
public class ControlHelper
{
public virtual String GetControlName(Control control)
{
return control.Name.ToString();
}
// it is not possible to do the logic on a generic control, so force derived classes to provide the logic
public abstract void DoSomeFancyStuffWithControl(Control control);
// other common functions may come here
}
public class LabelHelper : ControlHelper
{
// you may override virtual methods from ControlHelper. For GetControlName, it should not be the case
public override DoSomeFancyStuffWithControl(Control control)
{
var button = control as Label;
// ...
}
// does not have to be virtual, but allow further inheritance
public virtual String GetText(Label l)
{
return l.Text;
}
// other label specific methods come here
}
public class ButtonHelper : ControlHelper
{
public override DoSomeFancyStuffWithControl(Control control)
{
var button = control as Button;
// ...
}
public virtual bool GetEnabled(Button b)
{
return b.Enabled;
}
// other button specific functions may come here
}

preventing sub class methods to run from base class constructor

The question title seems a little bit odd doesn't it. Anyway. So I have one base class which has some private fields, protected properties and a single constructor that takes one argument and I have several sub classes of that base class. whenever any of those subclass methods are called the sub classes are required to be instantiated and after the method is done executed the object is destroyed so if the method will be called again new instance of the class should be made. (Its a WCF service) Now, the thing I want to do is the following. whenever the certain sub class constructor is called I call the base class constructor explicitly with some certain parameter (different for every sub class, Note: no sub class methods are the same), When the base class constructor is called I want to check something according to that argument and if it passes the check then I want to allow the execution of sub class method. In any other case I want it NOT to run the sub class method. So I want something like this. when the method is called the sub class has to be constructed and for that, base class has to be constructed as well and if the check fails in the base class' constructor I want to prevent that method from running. I can just have a bool property and set it in base class' constructor and check it on every method call. but I want to make something more general. May be the way that I'm suggesting Is not right either. So you understand what I want I guess. Any suggestion would be appriciated. thanks in advance
class BaseClass
{
private bool _isValid;
private SomeService someService;
public BaseClass(SomeEnum value)
{
someService = new SomeService();
if (someService.Validate(value))
{
_isValid = true;
}
}
protected internal bool IsValid { get { return _isValid; } }
}
class SubClass : BaseClass
{
// object declaration
public SubClass () : base(SomeEnum.SomeValue)
{
// constructing some objects here
}
public Response Operation('parametereGoHere')
{
if (IsValid)
{
// perform operation. construct Response object and return it
}
}
// other methods omitted.
}
So whenever the Operation() method is called SubClass has to be constructed which causes the BaseClass to be constructed and the base class sets the value of _isValid which is then use to check for validity, but I wanted to make something more general. lets that instead of just setting the value of _isValid to true just do nothing or set some other properties and if the Valiate() failed just stop the execution and don't to anything at all. In this case the calling routing wouldn't be able to call Operation() if we somehow managed to stop the construction of class. If it's not possible I'm perfectly happy with the solution I have right now. But if it is I will be glad to see that. Note: In every sub class, methods are different and I have to check IsValid to allow the execution of method.

You should be able to use the out parameter to get the constructor to return a value.

Very hard to follow what you want, but it sounds like you want a case where the base constructor doesn't do anything sometimes. Then simply make a base constructor that doesn't do anything, and call it (with the : base() call). Use a dummy argument if necessary.
class A {
public A() { a= 1; }
public A(double dummy); { }
}
class B
public B() : base() { // calls the base constructor that does something
}
public B(int) : base(1.0) {// class the base construct that does nothing
}
}

How to access parent form from the child form?

I've tried looking this up and I couldn't find anything that I understood.
But what I'm trying to do is create a class with all my functions in, then call it from the parent form.
And one of these functions contains adding controls to the parent form, but I cannot find out how to do this, can somebody help me please and explain it along the way?
Many thanks,
Jarrod

Typically, I'd just add a reference to the parent form in the lower class and initialize it in the constructor. Something like this:
public form MyForm : Form
{
Foo myFoo;
public MyForm()
{
this.myFoo = new Foo(this);
}
}
public class Foo
{
private MyForm parentForm;
public Foo(MyForm parent)
{
parentForm = parent;
}
}
Then you can reference the parent form and manipulate it how you wish. It also works for static classes, too.

Try this;
In your class use this method to add controls to Parent form
public static void AddControl(Form ParentForm,Control control,Point location)
{
control.Location=location;//This is only to show you
Parent.Controls.Add(control);//how it can be done.You can replace this logic with yours
//but make sure to add this Parent.Controls.Add(control),where control will be the name of your Control.
}
Then whenever you need to add a control call the function as;
ClassName.AddControl(this,new TextBox(),new Point(10,10));//Change ClassName to your class's name.
Anything else please let me know.

How can I restrict a class to be creatable only within another class?

I've been breaking my brain to figure out how to do this in C#. I have a TextGrid class, which is essentially an MxN grid of text. I'd like to have a Cursor class that maintains an (X, Y) position in a TextGrid, as well as methods for moving the position, querying the current position, etc. Ideally, I'd like for this class to not be creatable outside of TextGrid, since it's useless without being logically attached to a TextGrid.
However, my approaches for tackling this aren't up to par: I've tried having 1) Cursor be a public class nested inside TextGrid with a private constructor, 2) Cursor be a private class nested inside TextGrid with a public constructor, and 3) Cursor be its own separate public class outside of TextGrid with a public constructor. #1 doesn't work because I'm not able to instantiate a Cursor from within TextGrid due to the private constructor. #2 doesn't work because I can't return the created Cursor object outside of TextGrid (e.g. a GetCursor() method) due to access restrictions. And #3 doesn't help at all.
Pretty much, what I'd like to do is have the equivalent of Java's Iterator in C#. Is this possible?

Use #2, but return it by interface:
public interface ICursor
{
}
public class TextGrid
{
private class Cursor : ICursor
{
}
// This could be a property if it doesn't require much calculation.
public ICursor GetCursor()
{
}
}

While using an interface to solve the problem is a good approach, if you just want to have every instance of the Cursor class associated with an instance of the TextGrid class, you can simply require the creator to pass an argument of type TextGrid to the constructor as such:
public class Cursor
{
public Cursor(TextGrid owner)
{
...
}
}

Nested class with hidden constructor impossible in c#?

I' ve been doing some programming lately and faced an issue which i found weird in c#. (at least for me)
public class Foo
{
//whatever
public class FooSpecificCollection : IList<Bar>
{
//implementation details
}
public FooSpecificCollection GetFoosStuff()
{
//return the collection
}
}
I want the consumer of Foo to be able to obtain a reference to FooSpecificCollection, even perform some operations on it. Maybe even set it to some other property of Foo or smth like that, but not To be able to CREATE an instance of this class. (the only class that should be able to instatiate this collection should be Foo.
Is my request really that far-fetched? I know that people way smarter defined c# but shouldn't there be such an option that a parent class can create a nested class instance but nobody else can't.
So far I created a solution to make an abstract class, or interface available through the property and implement a concrete private class that is not available anywhere else.
Is this a correct way to handle such a situation.?

The way embedded classes work is that they, as members of the outer class, get access to private members of that outer class. But not the other way around (what is what you want).
You can shield the constructor of FooSpecificCollection, but then the Factory has to be part of FooSpecificCollection itself. It could enlist the outer class:
public class Foo
{
public class FooSpecificCollection : List<Bar>
{
private FooSpecificCollection () { }
public static FooSpecificCollection GetFoosStuff()
{
var collection = new FooSpecificCollection ();
PrepareFooSpecificCollection(collection);
return collection;
}
}
private static void PrepareFooSpecificCollection(FooSpecificCollection collection)
{
//prepare the collection
}
}

Make your nested class private and make the return value of GetFoosStuff IList<Bar> instead of FooSpecificCollection.
Also, there's a good chance that deriving from List<Bar> is a bug.

If you are creating a library for others to use, you could make the constructor internal. Anyone outside the library will not be able to access it. If you are concerned about calling the constructor in your own project, just don't call it outside the parent class.
We create classes all the time which are not directly related to other classes, but the constructors don't have to be hidden from non-related classes. We (the programmers) know the the objects are not related so we don't ever create an instance of one in the other.

There is a solution but I don't think I would use it in my App :)
The idea is to have derived class from FooSpecific which is private and can be used only inside Foo but has public constructor, so Foo can create its instances.
public class Foo
{
//whatever
public class FooSpecific
{
// Protected contructor.
protected FooSpecific()
{
}
// All other code in here.
}
// Private helper class used for initialization.
private class FooSpecificInitHelper : FooSpecific
{
public FooSpecificInitHelper()
{
}
}
// Method in foo to create instaces of FooSpecific.
private FooSpecific CreateFooSpecific()
{
return new FooSpecificInitHelper();
}
}

No, and it doesn't really make sense.
I mean the whole point is so that you could potentially return other instances; but who will be deriving from that class anyway? Certainly not any other classes (Because that would be wrong, and imply it shouldn't be hidden inside the main class), so ...