Home/ Questions/Q 1114027
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T02:56:48+00:00

I’m working on a toolbar type application. My current plan is to create a

  • 0

I’m working on a toolbar type application. My current plan is to create a “toolbar” class and a “button” class. The toolbar class would create an instance of the “button” for each item on the toolbar. Each instance of the “button” class would handle its button’s GUI events (Mouse Over, Click, etc). I also want to have global options that would affect how these GUI events are handled (highlite in a certain color on mouse over, etc). My problem is that I’m not sure how to let each instance “know” what the current values are for the global options.

What is a good way to handle this? One thought I have is to create an “Options” class, create a single instance of it in the main toolbar class, and then pass a reference to the button class in its the constructor.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Collecting all options in an Options class, per se, is quite OK.

    If the buttons need to know for other reasons which toolbar they’re in, they’ll keep a reference (for reference read “pointer” in C++, in case it needs to be reseatable;-) to their parent toolbar, and a simple read-only accessor in the toolbar class to return the reference/pointer to the shared options object would be nicer from many points of view (e.g., the ability to rapidly switch from one set of options to another by just switching the one pointer [[or reference]] in the toolbar).

    But if buttons don’t otherwise need any reference to their creator toolbar, I wouldn’t add one (a circular dependency if the toolbar also needs to keep references to the buttons) just for this purpose.

    Rather, if you’re sure “there can be only one” (all buttons in all toolbars use the same options), a static method in the toolbar class (again, with the simple purpose of returning the reference to the “one and only” options object) would suffice.

    I do like the idea of “going through the toolbar” (with a regular method or a static one, depending) rather than forcing each button to add the amount of state needed to separately refer to the “one and only option object”. Of course, a Singleton pattern is another similar alternative (e.g. via a static method in the Options class), but I have some antipathy for that DP as a matter of principle, so I’d rather “go through the toolbar”…

    • 0