On Fri, Dec 15, 2006 at 11:27:03AM +0100, Cristofaro Del Prete wrote:
> Youness Alaoui ha scritto:
> > I'm just wondering about something... Do you know (or did you understand, 
> > or does anybody else knows) why the 
> > bind on <Enter> does the bind on the <Leave> and why the bind on the 
> > <Leave> itself does a bind on the <Leave>.. 
> > couldn't it be directly a bind <Leave> "handleLeave" ?
> I haven't investigated too much about it, but I noticed that when I
> tried to remove the extra <Leave>, it looked like moving the mouse from
> the menu (that would be, the white part of the menu) to a smiley
> triggered the Leave event.
> 

humm.. yeah, I know what you mean, it's because a 'bind' on a window triggers 
the event for every child of the 
window (that's the Tk specs), I forgot about that, but I think the way we do it 
is really dirty, it's probably 
old code, we found out how to avoid those correctly now, we should do a :
bind $w <Leave> [list if [expr $w == %W] [list wm state $w withdraw ]]
(the [list] and [expr] are to avoid using curly braces { } because when you do 
that, the Tcl interpreter doesn't 
substitute variables in the character string 

> > Also, it still is weird that the <Leave> is being done before the 
> > buttonPress because the buttonPress does the 
> > insert before doing the wm state withdrawn... And the code inserts directly 
> > the symbol, it doesn't need to check 
> > which button was clicked and what symbol it represented, so it doesn't need 
> > the window to be still there... 
> The smiley is inserted when the button catches the event ButtonRelease,
> but ButtonPress triggers Leave, and the menu is withdrawn in the time
> between the click and the release of the physical button.
> This is also the reason why speed-clicks worked: if you click rapidly
> when the computer is still busy drawing the icons, it takes too time to
> handle the Leave event and the ButtonRelease manages to insert the smiley.
> 
perfect, I understand that now, and it makes perfect sense!
Maybe fixing the above thing with the <Leave> binding might also fix this 
issue.. just in case it's that "bad 
code" that causes this...

> > Also, isn't there a %X or %Y option for the <Leave> event that you could 
> > pass to the function so you don't need 
> > to do the [winfo pointerX] ? but I think it's still ok to leave it as it is 
> > since you can directly check the 
> > coordinates relative to the window.. 
> The %x and %y options for the Leave event hold "the position where the
> mouse pointer crossed the window, relative to the receiving window."
> Unluckily, these values are polled with a very large interval; for
> example, exiting the menu from its top-left corner with a normal mouse
> speed will set them to 8 and 2, instead of 0 and 0.
> 
yeah, so as I said, it's ok to leave it as it is, why change if no need to, 
right ? ;)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to