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

Answer 1

I'd rather advise you make your GameDate method to return a string then call it from your main project which are essentially what libraries are meant for. e.g.:

public static string CalculateDate()
{
    return month.ToString() + "/" + displayDay.ToString() + "/" + year.ToString();
}

//in your main project
LabelDate.Text = myLibrary.CalculateDate();

For accessing it from other controls in the same project, you should use a delegate - Provide a delegate which performs the addition, declare the delegate and invoke the function from your CaculateDate. Example:

public delegate void dateSet(string);

public void setDate(string date)
{
    labelDate.Text = date;
}

then in your CaculateDate method:

labeldate.Invoke(new MainForm.dateSet(), GameDate);

Answer 2

the propertie LabelDate is from the class of your userControl MainScreen, but you're not instatiating any userControl.. Which instance of MainScreen do you expect to modify then?

you should do

this.controlMainScreen.LabelDate = GameDate;

considering that you say in your comments, that you have

 FormMain.Designer.cs there is: this.controlMainScreen = new Adventurers_of_Wintercrest.UserControls.MainScreen();

Answer 3

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.