jerch hat geschrieben:@Alfons:
Wenn man das Pseudocode-Bsp. mit der for-Schleife weiter ausbaut, sprich ich habe eine fertige Anwendung mit funktionierender Oberfläche, möchte aber Teile davon einem refactoring unterziehen, z.B. einen Button mit einer Aktion hinzufügen etc. - Wie stellst Du sicher, dass die Logik nicht verloren geht bzw. noch korrekt arbeitet? Was passiert mit dem Rest aus dem Bsp. (das `do_sumthing_with_button`)?
Ok, dann schauen wir was passiert. Gehen wir davon aus:
Code: Alles auswählen
import DynTkInter as tk
root = tk.Tk()
class DynButton(tk.Button):
def __init__(self):
tk.Button.__init__(self,"DynButton",text='DynButton')
self.pack()
def do_sumthing_with_button(dummy): pass
def create_fancy_dynbutton(some_argument):
# init & return button from dyn classes
dynbutton_object = DynButton()
return dynbutton_object
for i in range(3):
do_sumthing_with_button(create_fancy_dynbutton(i))
tk.gui()
root.mainloop()
Mit tk.gui() hab ich den GuiDesigner eingebunden. Mit dem GuiDesigner machte ich dan den letzten Button grün und habe es dann mit export with Names wieder abgespeichert. Diesmal auf das Originalfile (davon wird übrigens ein Backup angelegt). Und was kommt dabei heraus? Das da:
Code: Alles auswählen
import DynTkInter as tk
root = tk.Tk()
class DynButton(tk.Button):
def __init__(self):
tk.Button.__init__(self,"DynButton",text='DynButton')
self.pack()
def do_sumthing_with_button(dummy): pass
def create_fancy_dynbutton(some_argument):
# init & return button from dyn classes
dynbutton_object = DynButton()
return dynbutton_object
for i in range(3):
do_sumthing_with_button(create_fancy_dynbutton(i))
tk.gui()
# ======= New GUI Container Widgets ======================
class Application(tk.Tk):
def __init__(self,**kwargs):
tk.Tk.__init__(self,**kwargs)
self.DynButton = tk.Button((self,'DynButton'),**{'text': 'DynButton'})
self.DynButton_1 = tk.Button((self,'DynButton'),**{'text': 'DynButton'})
self.DynButton_2 = tk.Button((self,'DynButton'),**{'text': 'DynButton', 'bg': 'green'})
self.DynButton.pack()
self.DynButton_1.pack()
self.DynButton_2.pack()
# ======= End New GUI Container Widgets ==================
root.mainloop()
Die Applikationklasse hattest Du nicht, also wurde sie vor mainloop angefügt. Aufgerufen wird sie auch nicht, weil ein solcher Aufruf auch nicht drin war. Am Rest ändert sich eben nichts. Hättest Du die Applikationsklasse gehabt, wäre von Klassendefinition bis erste Leerzeile nach __init__ ausgetauscht worden.
Jetzt kannst Du entscheiden, ob Du das statisch haben möchtest und Application verwendest. Dann müsstest Du, wenn du mit einer Schleife darauf zugreifen willst nach der init noch eine Liste einfügen. Oder Du verwendest den geänderten Button für alle Buttons etwa in class DynButton oder create_fancy_dynbutton oder do_sumthing_with_button.
Ach so, eine andere Möglichkeit anstatt unterschiedliche Namen wäre bei gleichnamigen Widgets auch eine Liste. Weiß aber nicht was besser ist. Evtl möchte man ja gerade indiziert darauf zugreifen? Gerade wenn man Widgets mit einer Schleife erzeugt, möchte man wohl indiziert darauf zugreifen, oder? Bei den Scripts verwende ich ja auch den Index.
Und der Index hat Vorteile. Beim GridLayout kann ich so einfach mit dem Button 'Hide' den Hintergrund löschen, bei dem alle Widgets den Namen NONAME haben.
Wobei natürlich noch unklar ist, wie das bei Container Widgets mit gleichem Namen ist. Alle dieselbe Klasse oder unterschiedlich? Frames könnten gleiche Inhalte haben aber auch unterschiedliche. Soll man bei hundert Frames gleichen Namens mit Inhalt, dann 100 Klassen erzeugen?
Nö, dynamische Inhalte sollte man vom Abspeichern ausschließen können. Sollte wohl die Methode saveOnlyCode oder Lock() auch für den export berücksichtigen.
