Apr-28-2020, 11:35 AM
Your code never calls display_bill because you buund the button incorrectly. command=display_bill, not command=display_bill(). The oj checkbutton does not work because you did not bind it to the oj variable.
These are really simple problems to find. You need to develop some debugging skills so you aren't waiting for someone to answer questions on the forum.
The first thing I did with your program was add a print statement to calculate_bill
That provided some information. Why was the calculate_bill called immediately? Why didn't pressing the "Calculate Your Bill" button call calculate_bill? The reason for both of these is because of this:
As for OOP or no OOP, using a class does not make object oriented programming. OOP is a design philosophy. You can write OOP machine language code. I wrote OOP C programs before OOP became a thing. It felt natural to organize my code into entities (objects) that had data (attributes/properties) and operations (functions/methods). If my entities did similar thing it made sense to reuse code and data structures (inheritance). If I had collections of similar entities it made sense to treat them generically based on their similarities (interface).
OOP makes sense for many kinds of problems. For your problem your objects would be your inventory. Solving your problem in a more OOP way I would create a class for each type of thing you sell. The item would know it's name and price so I could write a generic menu function that displays available items and prices, and a generic order function that calculates the cost of the order. I would drop the check boxes because I want to sell more than 1.
I could write this OOP version of your program without using a single class. My inventory items could be implemented using a dictionary. My inventory a list of inventory dictionaries, my menu and orders being a window and a function. No classes to be seen, but it would still be OOP.
These are really simple problems to find. You need to develop some debugging skills so you aren't waiting for someone to answer questions on the forum.
The first thing I did with your program was add a print statement to calculate_bill
def calculate_bill(): total = 0 if water.get(): total += 1 if oj.get(): total += 2 print('calculate bill', water, water.get(), oj.get(), total) return totalWhen I ran the program I saw this right away, before pressing any buttons.
Output:calculate bill PY_VAR0 False False 0
Then I pressed some buttons and I could not see the message again.That provided some information. Why was the calculate_bill called immediately? Why didn't pressing the "Calculate Your Bill" button call calculate_bill? The reason for both of these is because of this:
Button(app, text = "Calculate Your Bill", command = display_bill()).grid(row = 4, column = 0)This is a really easy error to make. You are using a function and it is very natural to add the brackets, but what does adding brackets after the function name do? It calls the function and returns the result. The result of display_bill is None (you can verify that with a print statement too). So your Button command was actually:
Button(app, text = "Calculate Your Bill", command = None)).grid(row = 4, column = 0)Next I played with the check boxes. Water works, but OJ does not. My print statement shows oj is False even when the OJ check button was checked. I look at where the check button is created and I see this:
oj = BooleanVar() Checkbutton(app, text = "Freshly squeezed OJ: $2").grid(row = 2, column = 0)You create a variable for oj, but there is no "variable=oj" when you make the Checkbutton.
As for OOP or no OOP, using a class does not make object oriented programming. OOP is a design philosophy. You can write OOP machine language code. I wrote OOP C programs before OOP became a thing. It felt natural to organize my code into entities (objects) that had data (attributes/properties) and operations (functions/methods). If my entities did similar thing it made sense to reuse code and data structures (inheritance). If I had collections of similar entities it made sense to treat them generically based on their similarities (interface).
OOP makes sense for many kinds of problems. For your problem your objects would be your inventory. Solving your problem in a more OOP way I would create a class for each type of thing you sell. The item would know it's name and price so I could write a generic menu function that displays available items and prices, and a generic order function that calculates the cost of the order. I would drop the check boxes because I want to sell more than 1.
I could write this OOP version of your program without using a single class. My inventory items could be implemented using a dictionary. My inventory a list of inventory dictionaries, my menu and orders being a window and a function. No classes to be seen, but it would still be OOP.