Modify Windows Forms Control from another Project

Question

I have a Control lblDate in User Control MainScreen. I would like to modify it in a method in class Date, which is in another project AoWLibrary. I can't reference it because AoWLibrary is a dependent of the first project.

I tried to make lblDate static but the compiler kept throwing errors at me, and I have a public property that Date can't seem to access:

    public Label LabelDate
    {
        get { return lblDate; }
        set { lblDate = value; }
    }

In class Date, I need public method CalculateDate to modify the Text property of lblDate

    public static void CalculateDate()
    {
        GameDate = month.ToString() + "/" + displayDay.ToString() + "/" + year.ToString();

    // LabelDate.Text = GameDate;
    // This is essentially what I need to do
    }

Also, I can't even access lblDate in other controls in the same project.

Answer 1

So, the general idea is that you need to keep track of what is in scope. There are a lot of ways to go about doing what you want to do, but any of them rely on objects referencing each other properly in ways you may not quite understand fully yet. Don't worry-- everyone has to work through this at some point.

The reason the compiler complained when you tried to make that member static is because the label itself is not static. Being tied to a single instance of MainScreen, it has no meaning in a static context, which is by definition a scope without any inherent reference to a particular MainForm.

Your Date class is, of course, a totally different context, too, but its non-static members do have access to an instance of Date. There isn't any path between these two contexts until you create it. The static route actually would have worked (look up the Singleton pattern: the idea being that you store the first and only instance of a class statically and refer to it from elsewhere) but is probably not good design. Other ways to do this are by passing to Date an instance of MainScreen (preferably through an interface) or even LabelDate itself. All of these could get the two pieces you need together to talk.

However, I would like to suggest you think about where your game state is being stored. Is it in the library or the consuming assembly? If the former, you might want to think about creating a complete GUIless model of the data that needs to be stored and manipulated in the library class and only consume that ready-made data as-is in the main application. The other alternative is that your model lives in the main application, and just calls back to your library as necessary. In this case you should probably stick for now to asking the library for answers (or at most listening for events in the library) and NOT expecting it to reach back to the application on its own (whether to get or provide information).

In figuring out how to do this you will probably find your scope management issues are much easier to handle. Even a little bit of good architecture can go a long way.

But if this is all a little overwhelming, don't stress it too much. It sounds like you are doing this for fun, which is a great way to learn. You'll come up against issues like this and will either hit on a good design or a not-so-good one, but either way you're wrestling with important concepts and will come away better for it.