The question is formulated clearly, I appreciate it, but it is way more complicated that it has to be. This approach is wrong. You should capture the essence of the real problem and try to reduce your application to something as simple as possible still having the same problem. Ask yourself: "in what simplest possible application I would have the same problem" and then describe it, even better, with a comprehensive code sample.
But this is just about time. I clearly understood the problem (or its comprehensible part). Basically, you are missing two important things.
First thing is: there is no such thing as "method on a page". A
TabPage
is just one of the controls, which is a member of some class, which can be your window class, some you custom or user control class, or something else. A method specifically related to this page can be a method of this class, that is, a static method, which can accept references to any control instances via its parameters. Or it can be an instance method of this class, which means that it can have the same or other parameter, plus one extra method, implicit one, "this" which is the instance of this class you can access inside the body of this method. That's all. This is a key: you need to understand that the problem is somewhat artificial: 1) the scope of the method is the class which instance is a parent (direct + indirect) of many control instances; 3) control instance references can be passed to it as arguments.
There is another thing you are missing? Did you notice that in the title of the question you are asking about method, and at the end, you are asking about "firing an event"? Those are very different things. You cannot really "fire" and event (correct terminology is "invoke event"). More exactly, you can only invoke the event in the method of the type declaring this event. Even if one class declared event instance, and you derive a class from it, you cannot invoke this event in the derived class. This is an important
fool-proof feature of .NET. Why so? Because it protects you from doing something which is
really never needed. This is a mean of
inversion of control: you only invoke some events in some declaring class (most likely, you don't do it at all, so you cannot invoke them, too; most likely, you are talking about events which are not yours), you only
handle the event in the code of other types. Instead, you really need to call some methods or properties related to the page in your handler of the
Click
events. By the way, in WPF its better to use its
commanding system:
https://msdn.microsoft.com/en-us/library/ms752308%28v=vs.110%29.aspx[
^].
I called your problems "artificial" but they are not completely artificial; there are no the obstacles you imagined, but some problems still exist: there is always a problem to organize the code in a neat way. You mentioned enabling and disabling some control. Again, this is not "firing events" but is calling
IsVisible
properties. You can write the
Name
attributes in your XAML, to make it generating instance names for the controls you want to operate, and set the property of each instance individually, by name, but this would be way to much of ad-hoc approach in many cases, and quite poorly maintainable if you have many such controls. Instead, you can group those controls and enable/disable the whole group. For example, you could put some control in the same
Panel
. By the way, you don't need to disable control on a hidden (non-selected)
TabPage
: they are invisible and cannot be used.
Well, some ideas… And no, we did not yest came to the point of showing you some code samples. I would prefer if you showed some code sample and asked some questions based on that. Note that your questions not only formulated in a complicated way, but also not specific enough for that. It's all right, you can ask your follow-up questions later. You can use "Improve question" any time.
—SA