@LiiNKSYS: Man erzeugt normalerweise die GUI *einmal* und ändert deren Inhalt, statt immer wieder Elemente hinzuzufügen und zu löschen.
Sternchen-Importe sind Böse™. Da holt man sich gerade bei `tkinter` fast 140 Namen ins Modul von denen nur ein kleiner Bruchteil verwendet wird. Auch Namen die gar nicht in `tkinter` definiert werden, sondern ihrerseits von woanders importiert werden. Das macht Programme unnötig unübersichtlicher und fehleranfälliger und es besteht die Gefahr von Namenskollisionen.
Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst.
Funktionen (und Methoden) bekommen alles was sie ausser Konstanten benötigen, als Argument(e) übergeben.
Namen werden in Python klein_mit_unterstrichen geschrieben. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase).
Man gibt keine Grössen als Pixelangaben vor. Die Grösse eines Fensters ergibt sich automatisch aus dem Inhalt.
Erstellen von Anzeigeelementen und deren Anordnung sollte man nicht komplett in zwei Blöcke trennen. Das macht es schwieriger nachzuvollziehen wie die GUI aufgebaut wird, und man hat unnötige Mehrarbeit wenn man davon Teile in eigene Funktionen oder Klassen herausziehen will. Es ist auch gar nicht konsequent durchgezogen worden.
Es empfiehlt sich da dann auch die Elemente nicht nach Typ zu sortieren, sondern in der Reihenfolge zu erzeugen in der sie angezeigt werden.
Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in aller Regel auch was in der Dokumentation von Python und den verwendeten Bibliotheken steht.
Falsche Kommentare sind schlimmer als keine Kommentare. Ein Kommentar sollen eventuelle Fragen mit dem Code klären, aber wenn dort falsche Informationen drin stehen, oder gar welche die dem Code direkt wiedersprechen, erreicht man genau das Gegenteil. Der Leser weiss dann nicht was falsch ist, der Code oder der Kommentar. Wenn da steht es geht um Labels und als erstes werden Entries erstellt, verwirrt das mehr als es hilft.
`Label_Ausgabe` wird im Hauptprogramm an ein `Label` gebunden das nirgends angezeigt wird.
Man nummeriert keine Namen. Dann will man sich entweder bessere Namen überlegen, oder gar keine Einzelnamen/-werte verwenden, sondern eine Datenstruktur. Oft eine Liste. Man muss aber auch gar nicht jedes Zwischenergebnis an einen Namen binden.
Beim `grid()` sollte man nich willkürliche Lücken bei den Spalten/Zeilen lassen.
Beim öffnen der JSON-Datei fehlt entweder die Angabe der Kodierung, oder man sollte die als Binärdatei öffnen.
Wofür sollte denn `window_close_cmd` stehen? Es macht keinen Sinn den Rückgabwert von der `quit()`-Methode an diesen Namen zu binden.
`event` ist kein sinnvoller Name für ein *-Argument. Das * ist hier aber auch fraglich, weil da ja tatsächlich (potentiell) nur *ein* Argument übergeben wird, nämlich das Ereignisobjekt. Wenn das Optional ist, dann gibt man dem einen Defaultwert und nimmt nicht einfach beliebig viele Argumente entgegegen.
Die `read_input_field()`-Funktion braucht auch einiges an Argumenten was sie da so verwendet.
`eingabefeld` wär ein guter Name für ein Eingabefeld, aber nicht den *Inhalt* von einem Eingabefeld.
Wenn man in einem ``if`` genau das Gegenteil von der Bedingung des ``if`` davor prüft, sollte das in der Regel eigentlich ein ``else`` sein.
Um die Bedingung bei ``if`` braucht es keine unnötigen Klammern.
Zwischenstand (ungetestet):
Code: Alles auswählen
#!/usr/bin/env python3
import json
import tkinter as tk
from functools import partial
def read_input_field(teile, input_field, ausgabelabel, _event=None):
teilenummer = input_field.get().strip()
for teil in teile:
#
# FIXME Die Logik hier stimmt so noch nicht.
#
if teil["Teilenummer"] == teilenummer:
ausgabelabel["text"] = str(teil)
else:
ausgabelabel[
"text"
] = f"{teilenummer} konnte nicht gefunden werden!"
# if teilenummer == "":
def main():
with open("inventar.json", "rb") as file:
teile = json.load(file)
window = tk.Tk()
window.title("Lagerprogramm v1.0")
tk.Label(window, text="Teilenummer: ").grid(row=0, column=0)
input_field = tk.Entry(window)
input_field.grid(row=0, column=1)
ok_button = tk.Button(window, text="Ok")
ok_button.grid(row=1, column=1)
tk.Label(window, text="Ausgabe: ").grid(row=2, column=1)
ausgabelabel = tk.Label(window)
ausgabelabel.grid(row=2, column=1)
tk.Label(window, text="Bestandskorrektur: ").grid(row=7, column=0)
input_field_bestand = tk.Entry(window)
input_field_bestand.grid(row=3, column=1)
callback = partial(read_input_field, teile, input_field, ausgabelabel)
ok_button["command"] = callback
window.bind("<Return>", callback)
window.bind("<Escape>", lambda _event: window.quit())
window.mainloop()
if __name__ == "__main__":
main()
Letztlich wird man für jede nicht-triviale GUI nicht um objektorientierte Programmierung (OOP) herum kommen. Also eigene Klassen schreiben.
