❔ Quitting to main menu in console app
The app is used to monitor a habit with saving the data to a database. The user has to insert a date and one number (for example how many glasses of water they drank that day) and I wanted to make it so writing 0 in the console would result in quitting to main menu, but with the way I did it first, it kind of "opens" another menu in that menu? I read that usually these kinds of apps are done with a "while" loop but they don't mention going back, only closing. How to untangle this mess? (I'll post code snippets in a second)
26 Replies
All you have to do to go back is... Nothing. When a function ends control automatically goes back to where it was
so I overcomplicated this probably 😅
Beginners typically keep calling 'menu()' thinking they're going back to the beginning, but in reality they're going deeper and deeper into a maze
haha that's what I did lol
but with this I can't just do nothing?
which probably means I have to kind-of-start-over
I don't know how much to paste here so it makes sense
Depends what is around this code, I guess
Basically all you need is
While not quitting
Show menu
Do action
And you can use the same pattern for sub-menus etc as well.
this is above
and this in Program.cs
told you, tangled mess XD
It's not too bad. Does 0 option set IsRunning to false?
yes and no
it returns false when 0 is written in the main menu
but not in the "submenus"/"options"
Ok. So is your problem specifically when you're in sub menus?
From your earlier question asking about doing nothing in option 2, yes, doing nothing should be fine afaict
yeah and it's because of this:
quitting runs a menu again hahaaa
Yeah ok. That's the problem
I don't know what to do about it so it probably means there's quite a bit to do again
Two tips. Try to make functionality do just one thing.
E.g why is getting a quantity mixed with quitting to main menu.
The other is you can have a function indicate whether to keep going or not by returning a bool
Like
bool TryGetInt(out int number)
How to define "one thing"? It's always an issue for me
Yeah it can be ambiguous
But getting a number is a different thing to a decision about menu navigation
hmm okay makes sense
Like, how should a small utility to ask for a number have the power to move through menus
No, they're completely separate concepts
So for the 0 to work as exit I should construct the procedures in a way that would lead to leaving the method (for example getting a date)? A sort of shortcut to "break;"?
Yes. For utilities getting data, they should always return something.
If you want the option for it to fail, or be cancelled, then it still needs to return, but you use the "try get" pattern
So
int getint()
or
bool TryGetInt(out int number)
ooh alright
that's so clever
This proved to be more tricky than I anticipated >.> for the 0 to work all that procedure for adding has to, in the end, become 1 function? I'd think so if it has to react immediately for that 0 on any stage 🤔
I don't really understand what youre saying
I'm not entirely sure myself
okay so um
if the only thing that changed was changing GetQuantity/GetDate to returning bool then it wouldn't stop the rest from executing even if it returned false
unless I got it wrong?
well something reacts according to the bool.
if true, then do something with data, if false then... whatever you want
and 'whatever you want' includes returning from the method, ie not doing anything else
that didn't work out :x whoops
I came up with this but it doesn't work for the date part because 0 isn't a valid dd-mm-yyyy format
it looks weird
why are they even returning a value that you dont use for anything
Seems like you save the data to VerifiedDate/Quantity, so
GetQuantity
should return a bool to say whether it worked or not
The while (true)
is pointless as wellWas this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.