Accessing vairable etc in a different class
-
I'm writing a C# application that has a form and then a seperate class that does some processing. I'm wondering if I can access the controls on the from from the other class. I want to do something like this:
Form.Control.[Property or Method]
so that I can access that information when I'm not in the class the form is defined in. Is this even possible? Help is much appreciated.
-
I'm writing a C# application that has a form and then a seperate class that does some processing. I'm wondering if I can access the controls on the from from the other class. I want to do something like this:
Form.Control.[Property or Method]
so that I can access that information when I'm not in the class the form is defined in. Is this even possible? Help is much appreciated.
-
YourForm yourform = someform as YourForm; //or just cast, same diff
yourform.YourMethod();I rated this article 2 by mistake. It deserves more. I wanted to get to the second page... - vjedlicka 3:33 25 Nov '02
If I do this I have access to default Form methods and such but not the methods that are specific to my form. Your explanation was a little confusing. Is "YourForm" the class of the form I want to use? What is "someform" representing? Thanks Again
-
I'm writing a C# application that has a form and then a seperate class that does some processing. I'm wondering if I can access the controls on the from from the other class. I want to do something like this:
Form.Control.[Property or Method]
so that I can access that information when I'm not in the class the form is defined in. Is this even possible? Help is much appreciated.
I believe the difficulty you're having is that you're thinking of the problem from the wrong angle. It's not a mechanical thing. It sounds like you want two peer classes to communicate, OR you want an owned class to be able to call back to its owner. The problem is that you're coming at it from the wrong angle. Instead of the worker class pulling information from the form, your form should push information to the worker class. Why? Because the worker class is many more times likely to be re-used than is the form class. Forms are usually the most specific part of your app, and worker classes the most general. If it is an owned class getting information from its owner, don't do it. Instead have the owner push the information down to the owned class. This reduces your coupling of the two classes which will allow you to re-use this class some day. Remember, the first rule of generalized classes is the "I'll never" rule. Right now you're saying "I'll never need to re-use this class" which guarantees that you will. If that class accesses specific controls and/or properties in your forms class, you won't be able to re-use it. If this doesn't describe your problem, let me know more specifics and I'll show you another angle.
-
I believe the difficulty you're having is that you're thinking of the problem from the wrong angle. It's not a mechanical thing. It sounds like you want two peer classes to communicate, OR you want an owned class to be able to call back to its owner. The problem is that you're coming at it from the wrong angle. Instead of the worker class pulling information from the form, your form should push information to the worker class. Why? Because the worker class is many more times likely to be re-used than is the form class. Forms are usually the most specific part of your app, and worker classes the most general. If it is an owned class getting information from its owner, don't do it. Instead have the owner push the information down to the owned class. This reduces your coupling of the two classes which will allow you to re-use this class some day. Remember, the first rule of generalized classes is the "I'll never" rule. Right now you're saying "I'll never need to re-use this class" which guarantees that you will. If that class accesses specific controls and/or properties in your forms class, you won't be able to re-use it. If this doesn't describe your problem, let me know more specifics and I'll show you another angle.
jpwkeeper wrote: If this doesn't describe your problem, let me know more specifics and I'll show you another angle. Unfortunately this doesn't really describe my problem. My problem is that I have a
RichTextBoxon myFormthat I need to add information to from the other class. I also have aTimeron the form that I need to access. So I'm not really trying to access information on theFormbut rather it's controls. I can't think of anyway to do this beside getting to the controls on theFormif you have another way I would appreciate hearing it. Thanks again. -
jpwkeeper wrote: If this doesn't describe your problem, let me know more specifics and I'll show you another angle. Unfortunately this doesn't really describe my problem. My problem is that I have a
RichTextBoxon myFormthat I need to add information to from the other class. I also have aTimeron the form that I need to access. So I'm not really trying to access information on theFormbut rather it's controls. I can't think of anyway to do this beside getting to the controls on theFormif you have another way I would appreciate hearing it. Thanks again.OK, assuming the class that needs to talk back is a member variable in your form class, you need a delegate so that the child class can push information back to the form. Once again, let me stress that the worker class shouldn't talk directly to the controls. Let the form do that, so that when you change the form in the future (you will, even if you don't believe me now) you won't have to worry about changing the worker to match. So, if your structure is roughly like this:
public class MyForm : //yada yada { Private MyWorkerClass m_cMyWorker = new MyWorkerClass; Private RichTextControl rtMyTextControl; }then you really need delegate callbacks from MyWorkerClass that MyForm hooks in to. This keeps them separate and uncoupled. You may have to alter your intended approach a hair, but I promise you'll thank me later if you do. Rather than explain delegates, let me point you to an incredible article Chris Sells wrote on the topic. It also talks about the evils of tight coupling (not to beat the drum too much): http://www.codeproject.com/csharp/delegate\_bedtime.asp