Assigning a null value to an event in one class from another class

[EARNEST]

Hello guys,
My program would allow a user to tweak its calculations engine via certain controls: radio buttons, check boxes etc. The problem is, based on such settings, appropriate events would take place that would either improve my programs performance (by disabling certain dynamic GUI updates) or slow it down (dynamic GUI control's updates).
To disable those GUI components, an event has to be assigned to null.
How can I do that from another class?

public delegate void StringSynch (string stringname);

public event StringSynch LogReportSynch;

            //log reporter
            if (dynamicLogOption == false)
            {             
                LogReportSynch = null;
            }

           
            
            if (LogReportSynch != null)
            {
                LogReportSynch(stepByStep_reportString);
            }

This is in 1 class, how would i assign it to null from another class(where my GUI is)? Any hints, pls?

[EARNEST]

Should I make the controls .Checked parameters as public static and access them in Class 1, like Class2.radBut1. Checked ?

[tlhintoq]

No. Never give public access to the controls themselves.
Make properties that have the power to do that.

public bool IsEnabled
{
     get { return radbut1.Checked; }
     set { radbut1.Checked = value; }
}

[EARNEST]

I would have quite a lot of controls, if i add method to check if they are Checked or not, it would add lots of extra code. Is there a better way?

[tlhintoq]

No. That's how it is done.

[EARNEST]

Hm...I understand that, thanks, but I cannot see how it would solve the problem :(
I will not be able to check if a control IsEnabled from another class, rather then its parent class. Am I wrong?

[EARNEST]

I don't think the way you proposed would work fine in my case.
I would have 3 classes: class1 (gui) would have those controls, class2(gui) would call a method from class3 with parameters based on class1 controls, class3 would see if the arguments T|F and will set the events appropriately. So, the property thing would only work for class2, since I instantiate class1 in class2, so class3 won't have access to the properties.
I was thinking of adding the boolean values of the controls in a list, and pass that list as list of parameters, and then check,

if list.elementat( i) = True|False, set event(i) True|False

[tlhintoq]

When your class (call it class A) checks to see if a checkbox is checked it is really checking the property of that checkbox class. This really does work.

I don't think the way you proposed would work fine in my case.

Rather than trying to guess and think if it will or won't work - why don't you *try*.

Just make one property in one class and reach it from another. We learn by doing.

[EARNEST]

Should I add some sort of a parameter for IsEnabled, since I would need to check like 10 controls?

[tlhintoq]

Yep. That's the idea

[EARNEST]

I think the best way is to use delegates. I tried to do that but I am stuck between the layers.
ClassA has buttons. ClassB checks if they are enabled or not, based on it, it sends info to ClassC that would assign null to appropriate events...
1)The other thing, since ClassB has instance of ClassA and ClassA's controls are public, I can use IsEnabled on those....
2) Using approach above, assign N number of public static boolean variables in ClassB and read them in Class3, but I think you said it is a bad idea. Why?

[EARNEST]

    public partial class My_GUI : Form
    {
My_LogOptionWindow logOptionWindow; //log option window form
        public static bool logWindow_gui_update;
        private void button1_Click_1(object sender, EventArgs e)
        {           
            logWindow_gui_update = logOptionWindow.cboxLOW_logReporter.Checked;
        }
}    public class ClassC
    {   
            if (!My_GUI.logWindow_gui_update)
            {
                LogReportSynch = null;
            }
}

[tlhintoq]

Bad: Directly accessing controls of one class/form from another.

bool IsOn = Form2.button1.IsChecked;

Good: Use a property to get such information

//Form1
bool IsOn = Form2.IsOn;

//Form 2
public bool IsOn
{
   get { return button1.Checked; }
   set { button1.Checked = value; }
}

It's a subtle but important difference as your applications become more complex. Using properties means your target class/form (Form2) can be changed and updated a thousand different ways yet won't negatively impact the classes that are reading from it. If you change the name of a control for example: No break in all your other classes. If your target form evolves where it needs to do 10 things when it is turned on, then the responsibility stays within Form2, and that burden on not put on Form1 and a dozen other forms that might be using Form2. The goal is to compartimentali ze the work so that Form2 is responsiblity SOLELY for Form2. From1 should only have to say "Turn on" or "Turn Off"

Form2
public bool IsOn
{
   get { return btnMeaningfulName.Checked; }
   set {
            btnMeaningfulName.Checked = value;
            panelDashboard.Visible = value;
            labelStatus = value == true ? "On" : "Off";
            btnRunNow.Enabled = value;
}

Now when Form1 tells Form2 to turn on, Form2 will check a box, make an entire panel visible, change its Status label to say 'On' and enable a Run Now button.

[EARNEST]

Hmm...check post above yours please.... I think it is very similar to your code, but the difference is that I have a direct access to my control, while you are accessing it via a property call. Am I right?

logWindow_gui_u pdate = logOptionWindow .cboxLOW_logRep orter.Checked;

vs

bool IsOn = Form2.IsOn;

.
Also, if I will have lots of controls to check, there is no guarantee I would remember all their names that I can pass the names as parameter, that is why I try to read their checked status thru the instance of the class.
Thanks

[tlhintoq]

Do as you like. People here can only make suggestions based on years of doing this. If you want to make your controls all public and access them directly then go right ahead. Your coding style and choices are entirely your own, and that is one of the things that I like about coding. It has a level of 'art' in which each coder creates there own style that becomes their signature. You don't need anyone's permission to make all your controls public.

Mind you, if you can't remember the name of the property then why are you able to remember the name of the control any better?

If you create a consistent style to your naming then you don't have to remember the control names because Intellisense will show you the property names as you type. It won't matter if your control is named chkBox1, CheckBox1, chkRunning so long as you have a style to your properties.

IsRunning
IsBusy
IsProcessing
IsEnabled
IsMultithreaded
Is64bit
IsSilent

Do the same thing with method. I consistently use methods of

Start()
Stop()
Quit()
LoadSettings()
SaveSettings()
GoIdle()
GoActive()
ReLaunch()

At which point I don't have to care about what that class does or what the control names involved. If I tell a class to ReLaunch() I know it will do its job. Period. I don't have to care what that job is. Maybe for *that* class it means load its settings all over again, start a new log file, make a beep, whistle Dixie, and set up a new UI.