invalid command in after script

Bonjour,

Pour ce qui est de savoir si c'est un 'bug' je vais m'abstenir vu mon niveau.
Je remarque juste que dans le code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

def after(self, ms, func=None, *args): """Call function once after given time.           MS specifies the time in milliseconds. FUNC gives the         function which shall be called. Additional parameters         are given as parameters to the function call.  Return         identifier to cancel scheduling with after_cancel.""" if not func: # I'd rather use time.sleep(ms*0.001) self.tk.call('after', ms) else: def callit(): try: func(*args) finally: try: self.deletecommand(name) except TclError: pass name = self._register(callit) return self.tk.call('after', ms, name)

---

Il n'est à aucun moment fait une référence au Widget.
Pour moi .after() est une méthode d'une instance (Misc) pour programmer un event via le gestionnaire d’événement, pas un 'bind' d'un event pour un Widget.
Comme toujours en Python celui qui écrit le code est 'responsable' (pas moi :oops:).

Pour ce qui est de patcher c'est pour cela que j'utilise ici type.

@+

Salut,

Citation:

---

Envoyé par PauseKawa

Il n'est à aucun moment fait une référence au
Widget.

---

Le lien vers le widget est construit ici:

Code:

---

1 2	name = self._register(callit) return self.tk.call('after', ms, name)

---

C'est alors qu'on crée la commande TCL associée à callit (via ._register) et qu'on la stocke dans la liste self._tclCommands.

Lorsqu'on passe par .destroy, le script TCL associé est "détruit" et la chose crée par self.tk.call('after', ms, name) se retrouve dans les choux => le message d'erreur initial.

On peut considérer cela comme "bug" car .destroy oublie de détruire certaines entités qui ont pourtant été construites.

- W

C'est bien ce qui me semble avoir compris.
Ce que je veux dire c'est que lorsque j’écris:

Code:

---

1 2	root = Tk() root.after(time, func)

---

Il me semble que root n'est en aucun moment cité.

Code:

---

self.tk.call('after', ms, name)

---

Non ?

Hu?!? On se réveille!!!

Code:

---

1 2 3 4

# création d'une instance de la classe Tk root = Tk() # appel d'une méthode de l'instance: root.after(time, func)

---

...Dans la méthode .after...
qui peut être le self de self.tk.call('after', ms, name)" sinon "root"?

Autre façon de patcher avec jonglerie entre "paramètre" de fonction et bound methods: je reprends mon ancien code.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

import tkinter as Tk   # attention (self) est paramètre de la fonction locale # mais il est utilisé comme "reférence" à l'instance: # --- le self de self._tclCommands est "objet"... def destroy(self): if self._tclCommands is not None: data = self.tk.splitlist(self.tk.call('after', 'info')) for ident in data: script, cls = self.tk.splitlist( self.tk.call('after', 'info', ident)) if cls == 'timer' and script in self._tclCommands: self.after_cancel(ident) self.destroy()   # ne patchons plus Tk.Misc, il faut appeler "explictement" la fonction. #Tk.Misc._destroy = Tk.Misc.destroy #Tk.Misc.destroy = destroy   root = Tk.Tk() val = Tk.IntVar() print(root.after( 3, lambda: val.set(1))) #print(root.after( 1, root.destroy)) print(root.after( 1, lambda: destroy(root))) root.mainloop() input()

---

- W

Je n'ai rien dit.

Code:

---

1 2 3 4 5 6 7 8

import Tkinter as Tk   root = Tk.Tk() e = Tk.Entry(root) e.pack() e.after(1000, root.destroy) e.destroy() root.mainloop()

---

Bonjour,

Désolé wiztricks: 'philosophiquement parlant' j'ai du mal à voir dans .after() une méthode propre à un widget.
Oui, on a besoin d'une instance (self) ayant pour parent Misc pour l'utiliser et after dépend de celle ci mais dans l'idée je ne vois dans cette méthode qu'un accès à l’interpréteur Tcl (de même que .send() par exemple).

Code:

---

1 2 3 4 5

>>> from tkinter import Tcl >>> tcl = Tcl() >>> tcl.after(6000, lambda: print('ok')) 'after#0' >>> ok

---

Sinon je préfère largement le dernier destroy m

Bonjour,

Désolé wiztricks: 'philosophiquement parlant' j'ai du mal à voir dans .after() une méthode propre à un widget.
Oui, on a besoin d'une instance (self) ayant pour parent Misc pour l'utiliser et after dépend de celle ci mais dans l'idée je ne vois dans cette méthode qu'un accès à l’interpréteur Tcl (de même que .send() par exemple).

Code:

---

1 2 3 4 5

>>> from tkinter import Tcl >>> tcl = Tcl() >>> tcl.after(6000, lambda: print('ok')) 'after#0' >>> ok

---

Sinon je préfère largement le dernier destroy mais à ce sujet:
Pourquoi utiliser self.destroy()

Code:

---

1 2 3 4 5

self.destroy()   # ne patchons plus Tk.Misc, il faut appeler "explictement" la fonction. #Tk.Misc._destroy = Tk.Misc.destroy #Tk.Misc.destroy = destroy

---

Pourquoi self.tk.deletecommand(name) ne détruit pas l'event timer pour l'interpréteur Tcl ? Une piste ?

Merci

Salut,

Citation:

---

Désolé wiztricks: 'philosophiquement parlant' j'ai du mal à voir dans .after() une méthode propre à un widget.

---

Je suis d'accord du point de vue de TCL maintenant, l'implémentation Tkinter (le code Python qu'il y a entre les deux) associe la commande produite par after à l'instance....

Citation:

---

Pourquoi self.tk.deletecommand(name) ne détruit pas l'event timer pour l'interpréteur Tcl ? Une piste ?

---

C'est là que j'ose parler de "bug" ou de "undocumented feature":
- bug: si on fait le ménage, autant le faire complètement mais quand on ouvre la boîte, c'est compliqué pour faire "propre",
- undocumented feature: le programmeur "sachant" que les .after sont collés au "widget" évite .destroy (ou les associe à root).
- W

Citation:

---

Envoyé par wiztricks

collés au "widget" évite .destroy (ou les associe à root).

---

C'est insuffisant comme le montre mon code en début de sujet

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try: import Tkinter as Tk except: import tkinter as Tk   root = Tk.Tk() val = Tk.IntVar() root.after(3, lambda: val.set(1)) root.after(1, root.destroy) root.mainloop() input()

---

Je me demande, à la limite, si on ne devrais pas gérer cela hors IHM (pour les gros projets), directement au niveau Tcl (Tkinter.Tcl). Après tout il est facile de suppléer le gestionnaire d’événement via une classe (Class Ge(Tkinter.Tcl), Ge(dict)/context manager, etc...) et comme vous le montrez bind intercepte le 'destroy'...
Je ne parle pas de patcher quoi que se soit mais de revoir le after car je penche maintenant (et vous comprendrez que cela m'est désagréable car j'aime bien Tkinter) pour cette réponse: bug.
Votre avis sur le sujet ?

@+

Salut,

Comme je le disais tantôt, si .destroy se propose de faire le ménage, les manques côté traitement des associations sur les ".alert" laisseraient pencher vers "bug".

Oublions un peu .alert. N'import quel callback se traduit par la construction d'une commande TCL et son pendant Python qui sera créé dans la registry associée au widget sous le compte duquel il (le callback) sera déclaré.

Le callback pourra faire référence à ce qu'on veut: un lambda vers une méthode d'un autre widget qui pourra appeler une méthode d'un autre widget...

Ces dépendances seront difficiles à maîtriser "par programme" et, à défaut, il appartiendra au programmeur d'éviter de faire "n'importe" quoi où plutôt de faire attention aux implications de ses appels à .destroy et/ou aux liens qu'il aura crée avec des widgets "volatiles".

Dans ce cas, ce n'est plus un "bug" mais une "feature": un truc que doit apprendre le programmeur Tkinter plus ou moins à ses dépends, difficile à documenter mais connu par les vieux barbus qui hantent les forums de discussion.

Ce n'est pas très gênant: c'est en général le cas pour toutes les bibliothèques un peu touffues...

- W