disable button on masterpage .net 4.0 (c#)

Question

Im trying to disable a button on the masterpage from a content page when certain criteria are met. I can change the text on masterpage buttons using session variables, but IM having a bit of trouble with this latest bit - any hints anyone?

Methedrine

Are you trying to do this in the code behind after postback to the server, or are you trying to do it on the client through Javascript? – Insolvable

Is this ASP.NET or ASP.NET MVC? – Crispas

Answer 1

On your Master Page you would have a public function like so:

public void EnableTheButton(Boolean enable) {
  btnTheButton.Enabled = enable;
}

On your content page you would write:

((MyMasterType)this.Master).EnableTheButton(false);

Dartboard

This worked fine, I know there are rights and wrongs in these things but Im just starting out really with c# so was looking for something simple - this suited me fine thanks – Methedrine

Answer 2

I would add a public method to your master page that does this, and let the content page call it. This can make things a lot easier and more object-oriented.

You can use the MasterType directive in the content page to strongly type the master page. This will make it easier to call your method.

<%@ MasterType virtualpath="~/Masters/Master1.master" %>

Ill

Answer 3

This is a common problem that comes up from many people, and there is a really "easy" way to make it work. However, if you plan on this application growing or being significantly complex, taking the easy way out will hurt you. Most of the other answers are going to tell you about the easy way. Let's at least discuss the right way.

First, let's be clear on the relationship between master and content pages. A content page should not directly invoke implementation-specific members on its master, or vice versa. They are separated by the Page-Master contract. What's happening at a logical level? Something is happening on the content page that should result in a specific button being disabled.

Now, since the button is on the master page, it should not be aware of the specific content page. So it should also not be the button's responsibility to call down to the page instance and check for the criteria, nor should it explicitly subscribe to a type-specific event.

So what to do? There should be some master data object (probably a singleton) that lives in a centrally available location across the request lifetime. Say, HttpContext.Items or Session. Being a master data object, it should be the single authority for managing these conditions you're talking about. It should raise an event when any of the data is changed, and anyone (such as your button) can subscribe to that event and make decisions based on the state. (Sample below)

If your app will be stupid-simple, then this is definitely overkill. But as you grow as a developer, and start to build more sophisticated systems, these are things you need to keep in mind to keep your apps simpler, more stable, and more maintainable.

Here's two concrete, real-world things this approach addresses, that come from my experience.

1. This one's pretty straightforward - if you need to swap out masterpages at runtime, you want to decouple your page and masterpage implementations completely. One masterpage might have things another doesn't. One specific case of mine is a bit extreme - we have dozens of masterpages nested up to 6 layers deep, swapping them in and out at runtime. But the principle of flexibility remains the same - look at how many questions there are on this site for how to change the masterpage at runtime!

2. This one's a little more heady, but still has very practical consequences. Breaking logical responsibilities into separate classes has one very important effect - it typically reduces the total number of logic branches (e.g. if statements) in your applications. Those are the single biggest source of bugs. If a class doesn't have any logic, it's pretty hard for it to have bugs! :) When you start to think about applications in terms of man-years and development staff over time, and measure in hundreds of thousands or millions of lines of code - fewer logic branches aggregated over the whole application has a real, measurable impact on stability and changeability. Maintenance and enhancements become more about arranging simple, stable components than doing code surgery.

Here's the example masterdata class:

public class MasterData
{
    private string _state1;

    public string State1
    {
        get { return _state1; }
        set
        {
            _state1 = value;
            OnDataChanged();
        }
    }

    private string _state2;

    public string State2
    {
        get { return _state2; }
        set
        {
            _state2 = value;
            OnDataChanged();
        }
    }

    public event EventHandler DataChanged;

    private void OnDataChanged()
    {
        if(this.DataChanged != null)
        {
            OnDataChanged(this, EventArgs.Empty);
        }
    }
}

Cb

Other than appealing to your sense of design, can you enumerate real-world problems with calling a method on the master page? I've used this approach quite a bit and it has served me well. – Ill

@Jonathan sure - I added two to the answer. – Cb