public void SwitchUC()
{
Form1.Controls.Clear();
}
The line of code did work for aslong I had it on a button, but now it's in a void it does not :/Quote:
Everything. You can't clear all controls from a form with one line.
You need to:And this for each individual control you want to remove (you can forloop them).
- Remove the event handler from the event
- Use Remove method to delete the desired control
- Call the Dispose method to release all the resources used by the control.
It worked because a button is an object reference. Still, without removing any event handler associated with a control and disposing the resources used by it, you will leave a lot of dirt behind.Quote:
Ah I see, well I don't want to clear the things from memory orso, since the thing I will clear is just UserComponent1 so I can get to UserComponent2 (and I want to be able to switch between those, so clearing it from a memory will just make the program running slow I guess). But isn't there anyways to make a void doing the 'Form1.Controls.Clear();' ?Quote:
In C# (well... basically any object oriented programming language) you can either have static objects (can only have one of them) or you can have instances of objects.
Forum1 is NOT a static object. You could (if you wanted to) create all sorts of copies of Forum1 and display them. The error you are getting is because you are not saying WHICH Forum1 you want to perform the action on...
It's like saying "Car.Unlock()" without saying what car to try to unlock.
The reason you get this error inside your void and not within the event handler (button press) is because that button press was already inside the Forum1 class... Therefor you can operate on it because everything is already local to it.
Think of this like being inside a car and me telling you to unlock the doors. It simply makes sense that I'm talking about the car you're inside... not a car that is across the parking lot.
Now... your method has no reference to the instance of a Forum1 object. As such it cannot do what you're asking of it.
Here's a simple (although not recommended) workaround to give you an idea of how it works...
Inside the forum1 code do something like...
public static Forum1 MainWindow;
Then inside the initialization of the forum say...
MainWindow = this;
Done! You can now just say Forum1.MainWindow.Blablabla
This is NOT recommended, it's just an example of how you could handle it if for some really strange reason you HAD to have access to it outside of itself without first passing any thing between the two separate classes.
Save the instance of the form in a global variable called myForm or something. Then, from your "void", you call myForm.Controls.Clear();Quote:
static class Program
{
private static Form1 myForm;
public static Form1 MyForm
{
get { return myForm; }
}
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
myForm = new Form1();
Application.Run(myForm);
}
}
public void SwitchUC()
{
Program.MyForm.Controls.Clear();
}
Good works great. Anyways, what would be wrong if I wanted to do some designing in here?Quote:
You could assign your global variable (myForm) a value in your Main procedure (or somewhere else, it's all up to you).
Something like this:
(Program.cs)
Then, when you want to refer to your form from inside your own method, you just doCode:static class Program { private static Form1 myForm; public static Form1 MyForm { get { return myForm; } } [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); myForm = new Form1(); Application.Run(myForm); } }
Many will probably argue that this is not the ideal approach, but I doubt you care much about design anyways.Code:public void SwitchUC() { Program.MyForm.Controls.Clear(); }
I don't mean design as in visual design. I just meant that normally you'd have the method "SwitchUC" in the UI class itself. It will also make everything a lot easier if you ever introduced multi-threading to your program.Quote:
Oh well in this case im not really planning on doing multithreading, although good to know. I didn't need the void later anyways, since the UserComponent I was wishing to call this void from, can either just do that line of code itself.Quote:
The way it works is I have a windows form, and multiple usercompononents. (For example UC1 = LoginScreen). On the login screen I have 2 masked textboxes, ID, Pass connected to mysql). After the button is clicked and everything is filled in correctly the form will clear and will add usercomponent2which is a form with anything else inside it. Etcetc.Quote:
No offense but that's really not the right way to be handling things...
If for some reason you MUST have multiple 'states' for your forum then I'd suggest writing a screenstate type system (mostly used on game programming type environments where you need various gamestats such as menu screen, gameplay, paused etc while within the same program). The idea is that you create an object which represents the current state of the screen and then within the main program (form) you track and can easily swap between them using simple methods rather then the way you're handling it right now.
That being said... if I'm understanding you correctly (unlikely, I tend to make big leaps when I read things ahhaa) then you're prob best off just using some sort of winform control like tab controls.