Member Avatar for sumitrapaul123

Hi,

I have two buttons (button1 and button2) in a form which does two different things.
button1 instantiates class A and does something and similarly button2 instantiates
class B and does something.

private void button1_Click(object sender, EventArgs e)
        {
            A a = new A();
            a.DoSumthingWithA();
        }

        private void button2_Click(object sender, EventArgs e)
        {
            B b = new B();
            b.DoSumthingWithB();
        }


public class A
    {
        public void DoSumthingWithA()
        { 
            // do something and 
            // fire a event to display a text in the form in a label all the subscribed clases should do this function.
        }
    }

    public class B
    {
        public void DoSumthingWithB()
        {
            // do something and 
            // fire a event to display a text in the form in a label all the subscribed clases should do this function.
        }
    }

Now I want that whenevr anyone of the method gets execute an event should get triggered just to change the font of
a text in a label in the form.

now from where which class I should write the code to publish the event and where should I write the code to subscribe it.

I may have many more buttons in future which should also change the font.

Please help.

Regards,

  • 2 Contributors
  • 3 Replies
  • 119 Views
  • 1 Hour Discussion Span
  • Latest Post Latest Post by sumitrapaul123

Dani AI

Generated

The approach already shown by (publish the event where the action happens, subscribe from the UI) is a reasonable, idiomatic starting point — as already noted. Classes A and B are natural publishers because they know when the font-change-worthy action occurs; the WinForms Form is the natural subscriber because it owns the label and the UI thread. For reference on language-level best practices see the official C# events guidance: C# events.

When the number of producers grows, consider one of these cleaner alternatives instead of wiring many ad-hoc subscriptions:

  • A simple service API that producers call (invert control). A central IFontService keeps UI subscription logic in one place instead of many event hookups:
public interface IFontService
{
    void RequestFontChange(System.Drawing.Font font);
}
  • An event-aggregator / pub-sub mediator. Producers publish to the aggregator; the form subscribes once. This decouples lifetimes and makes unit testing easier.

Practical tips and pitfalls:

  • Subscribe once (Form.Load or when an instance is created and kept as a field). Unsubscribe in Form.Closing/Dispose to avoid lifetime issues when publishers outlive subscribers.
  • Use strongly typed EventHandler<TEventArgs> and meaningful event names (e.g., FontChangeRequested).
  • If events may be raised from background threads, marshal updates to the UI thread (Invoke/BeginInvoke).
  • For long-lived/global publishers consider weak-event patterns or explicit unsubscribe to prevent preventing GC of subscribers.

Bottom line: the current design is fine for a handful of classes. For a larger system, centralizing the font-change responsibility (service or aggregator) improves maintainability and avoids subscription management headaches.

Recommended Answers

All 3 Replies

Member Avatar for sumitrapaul123

I have done something but is my way of doing is the best ??

Please see my code below:

public interface ICommon
    {
        event EventHandler ChangeFont;
    }

 public class A : ICommon
    {
        public void DoSumthingWithA()
        { 
            // do something and 
            // fire a event to display a text in the form in a label all the subscribed clases should do this function.

            FireEvent();
        }

        public event EventHandler ChangeFont;

        private void FireEvent()
        {
            if (ChangeFont != null)
            {
                ChangeFont(this, new EventArgs());
            }
        }
    }

    public class B : ICommon
    {
        public void DoSumthingWithB()
        {
            // do something and 
            // fire a event to display a text in the form in a label all the subscribed clases should do this function.
            FireEvent();
        }

        private void FireEvent()
        {
            if (ChangeFont != null)
            {
                ChangeFont(this, new EventArgs());
            }
        }
        public event EventHandler ChangeFont;
    }

the winform which 'should' subscribe to seeing the fired events



 public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

        }

        private void button1_Click(object sender, EventArgs e)
        {
            A a = new A();
            a.ChangeFont += new EventHandler(a_ChangeFont);
            a.DoSumthingWithA();
        }

        private void button2_Click(object sender, EventArgs e)
        {
            B b = new B();
            b.ChangeFont += new EventHandler(b_ChangeFont);
            b.DoSumthingWithB();
        }

        void b_ChangeFont(object sender, EventArgs e)
        {
            label1.Text = "Edited";
        }

        void a_ChangeFont(object sender, EventArgs e)
        {
            label1.Text = "Edited";
        }

    }

it is working but is this the right way to do ?? is the design fine ???
Actually like class A and B there will be many classes.

any thought wud be very much appreciated.

Thanks.

Member Avatar for ddanbe

Seems OK to me. If in more doubt just google, lots of explanations and tutorials out there. Example

Edited by ddanbe because: typo
Member Avatar for sumitrapaul123

actually what I was thinking was, since like class A and B there will be many new classes.
So is there any other better way to design the class ??

Thanks for reading and reply.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.