invalid command in after script

Version imprimable

Bonjour,

J'obtiens un message rouge dans la log de la part de Tkinter
Code:

1 2 3 4 5 6 7 8 9 invalid command name "156099928callit" while executing "156099928callit" ("after" script) invalid command name "156099248callit" while executing "156099248callit" ("after" script)
Je me doute bien que l'erreur est levée par un callback que j'ai passé en argument à une instruction widget.after(), mais j'en ai plusieurs.

Connaisez vous un moyen d'avoir plus d'informations sur ce type d'erreur ?
Merci d'avance

06/12/2011, 00h04
fred1599

Tu viens sûrement de créer une boucle infinie avec after et si tu ne donnes pas de moyen de sortir de cette boucle, ça doit faire cette erreur.

Enfin je pense, et sans code difficile à dire...
06/12/2011, 17h20
afranck64

Euh, c est pas très jolie, mais ca marche à tous les coups.
Il vous suffit de parsemer votre de code de "print (infos_relativ_au_after_plus_numero_ligne)" juste avant d appeler "after" L ensemmencement se fait du haut vers le bas (pour ne pas modifier les valeurs des lignes déjà validées.)
06/12/2011, 19h56
PauseKawa
Je doute que cela fonctionne: La fonction callit() registered par .after() est interne à Tkinter, ce n'est pas l'ID de la fonction mais celle de callit() que vous avez à l'écran.
Il n'y a pas du thread la dessous ?

Sinon l'erreur est facile a reproduire
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()
C'est donc bien l'objet qui n’existe plus pour Tkinter (Pas pour Python, ce n'est pas un NameError).

@+
06/12/2011, 20h54
afranck64

Citation:

Envoyé par PauseKawa

C'est donc bien l'objet qui n’existe plus pour Tkinter (Pas pour Python, ce n'est pas un NameError).

Je comprends bien, de par les explications, mais le code ne fonctionne pas (je veux dire, ne produit pas d'erreur.) lancé avec: PyScripter

Encore lui... (PyScripter).

Code:

1
2
3
4
5
6
7
patrice@Zeus:~/Bureau$ /usr/bin/python3.1 testerreur.py 
invalid command name "3076420044callit"
    while executing
"3076420044callit"
    ("after" script)
 
patrice@Zeus:~/Bureau$

08/12/2011, 11h25
shaiHulud
Bonjour, et merci beaucoup pour vos réponses.
J'ai isolé mon bug dans l'exemple suivant:
Code:

1 2 3 4 5 6 7 8 9 10 import Tkinter as tk def disp(x): print(x) def go(): R= tk.Tk() R.after(1000,lambda *a: disp(3)) R.mainloop() RR= tk.Tk() RR.mainloop() if __name__ == '__main__':go()
Si j'attends 1sec avant de fermer la première fenêtre R, pas de bug. Si je la ferme avant le délai d'1 seconde, le R.after() est toujours "en pile", et cela lèvera une erreur dans RR.mainloop() (erreur non levée si on commente RR.mainloop() !).

- Pourquoi RR.mainloop() essaye de s'occuper de R.after() ? R et RR ne sont elles pas 2 roots indépendantes ?
- Comment puis-je faire pour que le callback que je donne à R.after() n'existe plus une fois que R a été destroy() ? J’espère que cela corrige l'erreur.
- Dans l'idéal, cela concerne aussi tous les widgets que l'on a placé dans R et qui ont subi un after() (sont-ils destroy lorsque l'on destroy la root ?)

Merci d'avance

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
27
28
29
30
31
32
33
34
35
import Tkinter as tk
 
def disp(x):
    print(x)
 
def onquit(w):
    if hasattr(w, 'ids'):
        for event in w.ids:
            try:
                w.after_cancel(event)
            except:
                pass
    try:
        w.destroy()
    except:
        pass
 
def go():
    R = tk.Tk()
    R.ids = []
    R.ids.append(R.after(1000, lambda: disp(1)))
    R.ids.append(R.after(3000, lambda: disp(3)))
    R.ids.append(R.after(4000, R.quit))
    R.ids.append(R.after(5000, lambda: disp(5)))
    R.protocol("WM_DELETE_WINDOW", lambda: onquit(R))
    R.mainloop()
    onquit(R)
 
    RR = tk.Tk()
    RR.protocol("WM_DELETE_WINDOW", lambda: onquit(RR))
    RR.mainloop()
    onquit(RR)
 
if __name__ == '__main__':
    go()

08/12/2011, 22h16
shaiHulud

Merci beaucoup PauseKawa.

Je dois néanmoins enlever le 2eme onquit() (après R.mainloop()) pour mes besoins, mais ça a l'air de marcher avec comme sans ce 2nd appel.
09/12/2011, 00h01
shaiHulud

il reste tout de même un léger problème : j'ai appelé after sur des widgets non top-levels.
* Peut on appeler protocol('destroy') sur un tel widget ? (j'ai l'impression que non)
* Comment puis-je connaitre dans quel top level est situé un widget ?

Merci d'avance
09/12/2011, 10h20
wiztricks

Salut,

Citation:

Envoyé par VV33D

il reste tout de même un léger problème : j'ai appelé after sur des widgets non top-levels.
* Peut on appeler protocol('destroy') sur un tel widget ? (j'ai l'impression que non)
* Comment puis-je connaitre dans quel top level est situé un widget ?

Merci d'avance

Je ne pense pas que .destroy soit un "protocol": c'est une méthode.
Tkinter 'range' les widgets dans une arborescence issue de root (créée par tk.Tk())). Chaque widget a pour attributs:
- children: côté Tkinter c'est un dict dont la clé est le nom du widget qui par défaut est construit avec l'id de l'instance,
- master: le "parent",

=> Lorsqu'on remonte en suivant "master", le Toplevel sera la première instance X vérifiant isinstance(X, (Toplevel, Tk)).

Cordialement,
- W
09/12/2011, 13h56
shaiHulud

Merci Wiztricks ;)
09/12/2011, 21h32
wiztricks

Ooops.
Juste en regardant l'API pour autre chose, la méthode .winfo_toplevel permet de récupérer le toplevel directement (sans parcourir .master).
- W

Bonjour,

Pour ce qui est de:

Citation:

Envoyé par VV33D

il reste tout de même un léger problème : j'ai appelé after sur des widgets non top-levels.
* Peut on appeler protocol('destroy') sur un tel widget ? (j'ai l'impression que non)

Ou: Comment savoir si un Widget non Toplevel est 'destroy'
Je ne vois pas comment faire avec Tk. Pour le moment je reste dans des 'versions' Python du style

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
27
28
29
30
31
32
33
34
35
try:
    import Tkinter as Tk
except:
    import tkinter as Tk
 
def Trace_Maker(widget, func, master, *kwargs):
    def destroy(self):
        self.var.set(self)
        for c in self.children.values():
            c.destroy()
        self.tk.call('destroy', self._w)
        if self._name in self.master.children:
            del self.master.children[self._name]
        self.Misc.destroy(self)
 
    var = Tk.StringVar()
    var.trace_variable("w", func)
 
    cls = type(widget)
    cls = cls('Trace_%s' % widget.__name__, (widget,),
              {'var': var, 'destroy': destroy, 'Misc': Tk.Misc})
    return cls(master, *kwargs)
 
def callback(*args):
    w = r.globalgetvar(args[0])
    print(('Widget %s deleted') % w)
 
r = Tk.Tk()
l = Trace_Maker(Tk.Label, callback, r, {'text': 'Delete me !'})
l.pack()
t = Tk.Toplevel()
Trace_Maker(Tk.Button, callback, t, {'text': 'Delete me !'}).pack()
Tk.Button(r, text='Delete label', command=l.destroy).pack()
Tk.Button(r, text='Delete top', command=t.destroy).pack()
r.mainloop()

Salut,

PauseKawa: pourquoi ne pas passer par un event?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import tkinter as tk
 
def destroy(event):
    widget = event.widget
    print ('deleted ,', widget._w)
 
 
root = tk.Tk()
root.bind_all('<Destroy>', destroy)
 
label = tk.Label(text='Delete me !!!')
label.pack()
 
tl = tk.Toplevel()
tk.Button(root, text='delete label', command=label.destroy).pack()
tk.Button(root, text='delete toplevel', command=tl.destroy).pack()
root.mainloop()

- W

10/12/2011, 20h10
PauseKawa

Bonsoir,

Et bien en fait .protocol() intercepte l'event alors que .bind() fait un callback.
C'est pour cela que je fais un self.var.set(self) (maladroit car il faudrait plutôt lancer directement la fonction) dès le début de la méthode.
C'est une erreur ?
Maintenant c'est vrais que si nous n'avons rien a faire que le Widget existe encore ou pas (c'est le cas ici) bind est bien plus simple.

@+
10/12/2011, 20h54
wiztricks

Salut,

Citation:

Envoyé par PauseKawa

Et bien en fait .protocol() intercepte l'event alors que .bind() fait un callback.
C'est pour cela que je fais un self.var.set(self) (maladroit car il faudrait plutôt lancer directement la fonction) dès le début de la méthode.
C'est une erreur ?

no idea!
En fait, je ne suis pas sûr d'avoir compris le but.
VV33D a fait un autre post sur un sujet similaire. Et j'ai pu constater que, par défaut, root.protocol("WM_DELETE_WINDOW") invoque .destroy.
- W
10/12/2011, 21h30
shaiHulud

Pour l'instant, j'ai une solution partielle, qui combine vos 1ers posts:
Je surcharge after de sorte que l'id renvoyé par after soit stocké dans le toplevel master (attribut ids de pausekawa), puis je bind cancel_after à master.destroy.

Pour avoir une solution 'parfaite' il faudrait que widget.destroy() désinscrive ses after, comme wiztricks le suggère : root.bind_all('<Destroy>', destroy)

Mais les widgets peuvent déjà avoir été bind ! Comment faire pour ajouter un callback dans .bind() ou .protocol() sans perdre l'ancien callback ?

C'est le sens de ma question #1 dans mon autre post.

Bonjour,

Citation:

Envoyé par wiztricks

Salut,

no idea!
En fait, je ne suis pas sûr d'avoir compris le but.
VV33D a fait un autre post sur un sujet similaire. Et j'ai pu constater que, par défaut, root.protocol("WM_DELETE_WINDOW") invoque .destroy.
- W

On est bien d'accord sur cela et sur le fait que .bind() intervient après l'event et .protocol() l'intercepte.
.protocol()/.wm_protocol() n'est utilisable qu'avec les 'fenêtres' (instance Tk/Toplevel) et il n'existe pas de méthode pour les Widgets.
Dans l'exemple suivant l'Entry reste utilisable car le .destroy() de BaseWidget (et en particulier son self.tk.call('destroy', self._w)) est écrasé par un pass.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
try:
    import Tkinter as Tk
except:
    import tkinter as Tk
 
def Trace_Maker(widget, master, *kwargs):
    def destroy(self):
        pass
 
    cls = type(widget)
    cls = cls('Trace_%s' % widget.__name__, (widget,), {'destroy': destroy})
    return cls(master, *kwargs)
 
r = Tk.Tk()
v = Tk.StringVar()
l = Tk.Label(r, textvariable=v, bg='black', fg='white')
l.pack(fill=Tk.BOTH, expand=1)
e = Trace_Maker(Tk.Entry, r, {'textvariable':v})
e.pack()
Tk.Button(r, text='Delete entry', command=e.destroy).pack()
r.mainloop()

Nous avons donc bien un comportement 'proche' d'un Widget.protocol("WM_DELETE_WINDOW", fonction).
Bien sur il faudrait écrire cela en plus Tkinter (self.Misc), style le code de ttk.

C'est aussi la réponse à la dernière question de VV33D.
En utilisant une classe dérivée il est possible de lui ajouter les attributs que l'on souhaite, comme par exemple ids.
Cela donne (en gros, c'est dimanche après tout ;))

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
try:
    import Tkinter as Tk
except:
    import tkinter as Tk
 
def Trace_Maker(widget, master=None, *kwargs):
    def delete_events(self):
        for event in self.registered_func:
            try:
                self.after_cancel(event)
            except:
                pass
 
    def w_destroy(self):
        self.delete_events()
        for c in self.children.values():
            c.destroy()
        self.tk.call('destroy', self._w)
        if self._name in self.master.children:
            del self.master.children[self._name]
        self.Misc.destroy(self)
 
    def r_destroy(self):
        self.delete_events()
        for c in self.children.values():
            c.destroy()
        self.tk.call('destroy', self._w)
        self.Misc.destroy(self)
 
    def register(self, time, func):
        self.registered_func.append(self.after(time, func))
 
    try:
        if widget._w == '.':
            destroy = r_destroy
    except:
        destroy = w_destroy
 
    cls = type(widget)
    cls = cls('Trace_%s' % widget.__name__, (widget,),
              {'delete_events': delete_events, 'registered_func': [],
               'register': register, 'destroy': destroy, 'Misc': Tk.Misc})
    return cls(master, *kwargs)
 
def disp(x):
    print(x)
 
def go():
    R = Trace_Maker(Tk.Tk, None)
    #R = Tk.Tk()
    R.register(1000, lambda: disp(1))
    R.register(3000, lambda: disp(3))
    R.register(5000, lambda: disp(5))
    E = Trace_Maker(Tk.Entry, R, {'bg': 'red'})
    E.register(4000, lambda: disp(4))
    E.pack()
    R.mainloop()
 
    RR = Tk.Tk()
    RR.mainloop()
 
if __name__ == '__main__':
    go()

Salut,

Quand je disais ne pas comprendre le but, c'est parce j'avais l'impression que nous nous acharnions à vouloir faire fonctionner un truc qui pourrait être plus simple à réaliser si nous avions la possibilité d'avoir un peu de recul/hauteur.

Ceci dit, je pense de plus en plus qu'il s'agit d'un "bug" ou d'une feature dont les conditions d'utilisation mériteraient d'être documentées.

Reprenons le reproducteur de PauseKawa:
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()
Ca bugge parce que .destroy a nettoyé le script associé au timer sans effectuer le .after_cancel qui va bien...

L'id retourné par .after côté Python n'est pas celui du script:
Code:

1 2 name = self._register(callit) # nom du script return self.tk.call('after', ms, name) # ident pour after_cancel
Autrement dit, .destroy vire le côté Python de l'after mais pas le côté TCL!
=> looks like a bug, au sens ou ce pourrait être le boulot de misc.destroy d'aller "nettoyer". Ce qui pourrait donner:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 import tkinter as Tk 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() 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)) root.mainloop() input()
note: patcher au lieu de sous classer est une possibilité "Python" dont il ne faut pas non plus abuser...

- W

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.

@+

11/12/2011, 18h07
wiztricks
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
11/12/2011, 18h21
PauseKawa
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()

17/12/2011, 11h51
PauseKawa
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
17/12/2011, 11h54
PauseKawa
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
17/12/2011, 12h24
wiztricks

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
17/12/2011, 13h43
PauseKawa
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 ?

@+
20/12/2011, 00h12
wiztricks

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