download original
- Nicht-Orthogonalitaet (z.B. "Scrolled"-Pseudowidget, aber auch
Scrollproperties in etlichen Widgets, z.B. Canvas)
- Kompliziertes "configure"-Protokoll
- ($cnv ist ein Canvas)
DB<17> x $cnv->cget(-scrollregion)
0 0
1 0
2 4375
3 3540
DB<18> x $cnv->cget(-scrollregion)
empty array
?
- z.T. chaotisch organisierte Manpages (Tk::options, Tk::bind
usw.). Wo sind die Events dokumentiert, die ein bestimmtes Widget
aussenden kann? Tk::bind dokumentiert offenbar die
Tk::Widget-Events...
- Scrollables haben kein Event, das anzeigt, dass gerade gescrollt
wurde
- keine vernünftige Möglichkeit, eigene Events analog zu den
vordefinierten (mit "bind" bindbaren) zu definieren
- pro Event nur ein Binding definierbar???
$schedCanvas->CanvasBind('<Control-5>', sub {
print "bind1";
});
$schedCanvas->CanvasBind('<Control-5>', sub {
print "bind2";
});
=> bind2 überschreibt bind1, nur bind2 wird aufgerufen!!
- manche Events werden überhaupt nicht über "bind"-Listen verbunden,
sondern über einzelne Variablen (d.h. nur ein Binding pro
Event). Beispiel: Tk::Scrollbar/-command. Ein "Scrollable" verbindet
intern die "-command"s seiner Scrollbars. Setzt man die "-command"s
um, gibt es "witzige" Effekte...
- kein "visible"-Flag für Fenster; wenn Fenster geschlossen werden,
werden sie scheinbar automatisch zerstört -- Zustände der Widgets
gehen verloren
- "destroy"-Event eines Fensters wird mehrfach aufgerufen, wenn der
User das Fenster m.H.des Windowmanagers schließt (offenbar einmal pro
Kind des Fensters?)
back to tk
(C) 1998-2017 Olaf Klischat <olaf.klischat@gmail.com>