Moving from form to form

[isaiahk9]

I couldn't think of a better title to call this.
Basically, my final project is a game where you play as venom going around and engaging in combat and killing ghosts. Kinda random, but really addicting. I also fixed-up a menu from a scrapped prject and tacked it together, so now I have a decent game with a crazy menu. I can get from the loading screen to the main menu, and from there to the credits, high scores, tutorial, and back, to the exit screen and to the game screen.
However, I when I reach the game screen, after the game finishes running (when you lose), all forms dissapear when the program is supposed to redirect you back to the main menu.
Another problem I've noticed is that the screen don't actually dissapear - it's more like they are covered by the next form. So I was wondering if there was a better way of navigating forms than the way I'm currently using (say I am at FormA and going to FormB) :
FormB.Show
Unload FormA

Is there a better way that should fix my problems mentioned above? If so, thanx a lot.

[Vertico]

Normally I would just do something simple like

VisualBASIC:

Form2.Show() Me.Hide()

You could get a little more complicated and change the properties of the first form to the 2nd and close the first so only one form is ever used at anytime, but for what you need, this may be overkill.


For the "not going back to the main form" it just sounds like your not calling it correctly. Either through a loop or a direct call, you will want to check to see where the focus is heading when it finishes your code.

[isaiahk9]

Would you mind telling me the "overkill" method you mentioned, how only one form is ever open?

[Silent Avenger]

I think what he meant by overkill is actually closing the forms that aren't needed and thus freeing up memory but for what you are doing it isn't necessary. I always found that a sure fire way of getting the forms to appear and disappear is to use the visible property. Also if you are going to be detecting a loss in different ways (different parts of code) and you'll be copying the same code over and over you could make it into a procedure and call it when you need it.

VisualBasic:

Private sub loser()      Form1.visible = True      Form2.visible = False End Sub

And all you would need to do is call it whenever you need it.

VisualBasic:

Call loser

[isaiahk9]

.visible would've been fine, but my teacher specifically said to not do that. Anyways, I've already handed in the project, and I managed to fix or make up excuses for the bugs.

[Silent Avenger]

Ahh I see, kind of odd though for your teacher to tell you not to use the visible property which I find is the most straight forward way of making any object visible or invisible.

[isaiahk9]

Yeah, she didn't like it for something along the lines of that the form is just invisible but still there, so it is inefficient.

[DemonWasp]

It's a little inefficient, because the Form is still stored in memory (along with all the controls on it, and any other memory associated with it). However, if you keep going back and forth between the two forms, and memory isn't an issue, it could be inefficient to destroy and re-create the form each time.

"Efficient" isn't an absolute in computer science, since there's often a tradeoff between CPU-time, RAM usage, and other benchmarks. Things get even more complicated when you include caching effects, disk IO, page faults, and the operating system itself. In this case, you have a classic trade-off between RAM usage and CPU usage: either you can spend more RAM to store the form and avoid having to re-create it when you need it again, or you can spend more CPU to save a little RAM when you don't need the form.

[isaiahk9]

That's true, but, again - my teacher didn't want me to do that.