-1

I am somewhat new to Visual Studio (2019) and WinForms. I am currently trying to separate the two classes: one for form design and one for the project logic.

static class Program {
    static void Main() {
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
        // more logic
    }
}

public partial class Form1 : Form {
    public Form1() {
        InitializeComponent();
    }
    // design logic
}

Currently, I'm having difficulty transferring data between Program and Form1. I have tried creating public members to exchange this information, but I do not know how to access it (since the form is instantiated with the Application class.

I have considered leaving Program as is and moving all of the project code into Form1. Replacing the Application class with an instantiation of a form leads to the program not displaying the Form and terminating early.

Form1 foo = new Form1();

Is there a way to separate program and design logic, or should I put all the logic into Form1?

Thank you for the help.

ProgrammingLlama
  • 36,677
  • 7
  • 67
  • 86
General_Ocelot
  • 1
  • 3
  • _"Is there a way to separate program and design logic"_ -- yes, of course. But typically you'd leave `Program` alone and put the non-UI code elsewhere. Your question is unsuitable under the matured Stack Overflow standards, being far too broad and lacking any evidence of research on your part, but in the early days people got away with posting such questions. See duplicate for examples. – Peter Duniho Feb 19 '21 at 02:42
  • I did my own research and found nothing. That is why I posted this question. How exactly would you have researched this topic? – General_Ocelot Feb 19 '21 at 20:36
  • _"How exactly would you have researched this topic?"_ -- Hard to say, as I've been doing this so long that the topics I'd need to learn about, I already learned the hard way, decades ago. That said, _you_ certainly could have started with something like: https://www.google.com/search?q=windows+forms+design+patterns. That clearly shows all kinds of useful, applicable information. Your original question above shows zero evidence that you did any research at all, never mind what that research was. It's hard to believe that if you'd done any valid research at all, you'd've found literally nothing. – Peter Duniho Feb 19 '21 at 20:41
  • I will also note that the answer you've accepted, barely scratches the surface and doesn't really do anything at all to properly separate the concerns of the UI from the concerns of the _"project logic"_. Of course, as long as you're satisfied with it, it's your prerogative to accept the answer. Just please don't let that be the end of your education. – Peter Duniho Feb 19 '21 at 20:43
  • My question was specifically about separating design logic and program logic between the ```Program``` and ```Form1``` classes. I stated earlier I was new to Visual Studio and WinForms. I needed a specific question that could answer the use of the ```Program``` class and how others implemented their projects with WinForms. – General_Ocelot Feb 19 '21 at 20:48
  • _"My question was specifically about separating design logic and program logic between the Program and Form1 classes"_ -- see [XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). The fact is, no appreciable logic belongs in the `Program` class at all. That's just there to get the program started. Ignoring for the moment that the code posted with your question doesn't show any kind of non-UI logic in the `Program` class in the first place, the bigger problem is that simply running some code in the `Program` class doesn't address the broader defects in your code. – Peter Duniho Feb 19 '21 at 22:25

1 Answers1

0

Program is normally just a bootstrap class to start the app. You don't normally keep too much logic there.

Be that as it may, you must always use Application.Run so that you have a message loop to process system messages such as mouse and keyboard input.

But you could still use foo like this:

Application.Run(foo);
Charlieface
  • 52,284
  • 6
  • 19
  • 43