Quote Originally Posted by USNavyFish View Post
Hey folks, thanks for taking the time to read my post.

I'm trying to develop a clean way to organize my latest program (first time developing with C#). I'm trying to avoid global/public variables while at the same time trying to avoid massive chains of function calls, particularly on performance-sensitive blocks (i.e. rendering).
You don't have to worry about that, since C# doesn't allow global values.

Quote Originally Posted by USNavyFish View Post
So first off, I have a MainForm class, which represents the primary window of my application (and is utilized by the Application.Run() function within Main(). The first question I have is about this MainForm class - should I make this static? I have no intention of allowing multiple instances of the window open. The alternative to this would be to create a public instance of the MainForm class, stored in the Program class, so that other classes in my program can access the mainForm. The second solution feels a bit ugly, but is generally what I've done in the past. Any comments?
No need to make it static. Are you going to create two instances of it? Probably not, and no one else is either, so don't sweat it.

Quote Originally Posted by USNavyFish View Post
Next, I use an openGL control within my MainForm (thanks to the TAO library). I would like some other classes (particularly, the Graphics Class) to have access to this control, i.e. to determine its size etc. Currently, I pass it the the graphics class's constructor, and allow the graphics class to store a reference to the control locally. This again feels ugly, and basically entangles the two classes.
If you are worried about this, then just pass the size/position data.

Quote Originally Posted by USNavyFish View Post
It feels like I'm only really using classes to put code into separate files. They all end up horribly intertwined anyway! How do you handle this situation? Something I've considered is making various controls on my UI class read-only (not through the keyword but by creating a public property which only defines a get accessor), so that other classes can access but not modify them... but then this brings up the problem of having to create a program-wide public (global) instance of the UI! Kinda brings us back to square one.
There isn't any concept of global in C#. Classes shouldn't be designed based on file layout. You might want to read up on how to design a classes for a given problem. It doesn't really relate to files (btw, with partial classes, a class can be defined over several different cs files).