Mouse Bindings on Windows
#ROHIT DUGAR#
Hi All,
I want to bind mouse motions to a widget in such a way that when the user has held down the right mouse button (button-3) and he enters the widget, the action should perform.
bind .b <Enter> {
puts "I am Invincible"
}
does not work if the user enters the button 'b' with the right button pressed untill the user releases the right button. Is there a binding which would get executed when the right mouse button is held down, the mouse enters .b and the action (puts "I am Invincible" ) occurs.
thanx in advance
rohit
Aldric_Lhernault
bind .b <B3-Motion> {
puts "I am Invincible"
}
You may have a look into bind man pages for more events.
Hope this helps
regards,
Aldric
> I want to bind mouse motions to a widget in such a way that when the user has
> held down the right mouse button (button-3) and he enters the widget, the
> action should perform.
[SNIP]
Jeff Gosnell
#ROHIT DUGAR# wrote in message ...Hi All,
I want to bind mouse motions to a widget in such a way that when the user has held down the right mouse button (button-3) and he enters the widget, the action should perform.
bind .b <Enter> {
puts "I am Invincible"
}
Bryan Oakley
>
> Hi All,
>
> I want to bind mouse motions to a widget in such a way that when the
> user has held down the right mouse button (button-3) and he enters the
> widget, the action should perform.
>
> bind .b <Enter> {
> puts "I am Invincible"
> }
>
> does not work if the user enters the button 'b' with the right button
> pressed untill the user releases the right button. Is there a binding
> which would get executed when the right mouse button is held down, the
> mouse enters .b and the action (puts "I am Invincible" ) occurs.
>
The way bindings work, as long as a button is pressed, the widget that
handles the press event is the only widget that sees the motion event
(someobody correct me if I'm wrong or if it's slightly more complex than
that).
But, you can use this to your advantage. Remember that you can get the
absolute (root) x and y coordinates of the mouse with your event. And we
have the command [winfo containing], which tells us which widget
"contains" this x,y position. So, your command that handles the motion
can modify the appearance of widgets that it moves over, or perhaps send
them events to process (such as <<DragEnter>>, for example).
Here's a quick hack I just threw together to illustrate the
possibilities. The example is contrived and hard-coded for some specific
widgets, but you can see the general idea.
catch {destroy .l1 .l2 .reset}
label .l1 \
-text "Right-click and drag this label..." \
-bd 2 \
-padx 10 \
-relief groove \
-height 4
pack .l1 -fill x -pady 10
label .l2 \
-text "... and drag it over this label" \
-bd 2 \
-padx 10 \
-relief groove \
-height 4
pack .l2 -fill x -pady 10
bind .l1 <ButtonPress-3> [list drag start %W]
bind .l1 <Motion> [list drag motion %X %Y]
bind .l1 <ButtonRelease-3> [list drag stop %X %Y]
bind .l2 <<DragOver>> [list drag over %W]
bind .l2 <<DragLeave>> [list drag leave %W]
bind .l2 <<DragDrop>> [list drag drop %W]
button .reset -text "Reset" -command {
.l2 configure \
-foreground black \
-text "... and drag it over this label"
}
pack .reset
proc drag {command args} {
global _dragging
global _lastwidget
global _dragwidget
switch $command {
init {
# one-time code to initialize variables
set _lastwidget {}
set _dragging 0
}
start {
set w [lindex $args 0]
set _dragging 1
set _lastwidget $w
set _dragwidget $w
$w configure -cursor gobbler
}
motion {
if {!$_dragging} {return}
set x [lindex $args 0]
set y [lindex $args 1]
set w [winfo containing $x $y]
if {$w != $_lastwidget && [winfo exists $_lastwidget]} {
event generate $_lastwidget <<DragLeave>>
}
set _lastwidget $w
if {[winfo exists $w]} {
event generate $w <<DragOver>>
}
if {$w == ".l2"} {
$_dragwidget configure -cursor gumby
} else {
$_dragwidget configure -cursor gobbler
}
}
stop {
if {!$_dragging} {return}
set x [lindex $args 0]
set y [lindex $args 1]
set w [winfo containing $x $y]
if {[winfo exists $w]} {
event generate $w <<DragLeave>>
event generate $w <<DragDrop>>
}
set _dragging 0
$_dragwidget configure -cursor {}
}
over {
if {!$_dragging} {return}
set w [lindex $args 0]
$w configure -relief raised
}
leave {
if {!$_dragging} {return}
set w [lindex $args 0]
$w configure -relief groove
$w configure -cursor {}
}
drop {
set w [lindex $args 0]
$w configure -foreground red -text "THUD!!!"
}
}
}
drag init
(this was tested on an NT box; I assume it works just fine on Unix and
probably ought to work ok on the mac, too).
--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley
Chang LI
>
[snip]
The code is a wonderful demonstration.
I see it work for any many widgets.
It will work for the canvas at least.
Is it possible to use it drag a file from one directory to another
in the directory dialog? It seems no fundamental difficults.
> But, you can use this to your advantage. Remember that you can get the
> absolute (root) x and y coordinates of the mouse with your event. And we
> have the command [winfo containing], which tells us which widget
> "contains" this x,y position. So, your command that handles the motion
> can modify the appearance of widgets that it moves over, or perhaps send
> them events to process (such as <<DragEnter>>, for example).
>
> Here's a quick hack I just threw together to illustrate the
> possibilities. The example is contrived and hard-coded for some specific
> widgets, but you can see the general idea.
>
[snip]
--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
--------------------------------------------------------------
Bryan Oakley
>
> Bryan Oakley wrote:
> >
> [snip]
>
> The code is a wonderful demonstration.
> I see it work for any many widgets.
> It will work for the canvas at least.
It should work for all tk widgets. At least, all tk widgets that you can
bind motion and button press events to. There's no reason why it must be
limited to the canvas. In fact, my original example used labels.
>
> Is it possible to use it drag a file from one directory to another
> in the directory dialog? It seems no fundamental difficults.
Probably not, if the directory dialog is a native dialog (ie: not built
out of individual tk componants)
Frederic BONNET
Bryan Oakley wrote:
> Here's a quick hack I just threw together to illustrate the
> possibilities. The example is contrived and hard-coded for some specific
> widgets, but you can see the general idea.
Pretty impressive! It looks like a perfect basis for a more complete
framework (inter-application DnD, and so on).
See you, Fred
--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain
Bryan Oakley
>
> Hi Bryan,
>
> Bryan Oakley wrote:
> > Here's a quick hack I just threw together to illustrate the
> > possibilities. The example is contrived and hard-coded for some specific
> > widgets, but you can see the general idea.
>
> Pretty impressive! It looks like a perfect basis for a more complete
> framework (inter-application DnD, and so on).
Well, for inter-application DnD you have a couple of largish hurdles to
cross. For inter-tcl-application DnD it's fairly doable with send (or
applescript or the windows equivelent (dde?)). For DnD between tcl and
non-tcl apps, it's not nearly so cut and dried.
And while I appreciate your appreciation of the algorithm... it's
nothing special, and I'm certainly not the first to "invent" such a
scheme. It just uses some very basic binding techniques and a decent
understanding of how events are handled.
>
> See you, Fred
... and raise you, Wilma
#ROHIT DUGAR#
Hi Bryan,
But where can I find your algorithm (for the poor man's drag and drop)... That posting of yours doesn't seem to be here
Rohit
Bryan Oakley
>
> Hi Bryan,
>
> But where can I find your algorithm (for the poor man's drag and
> drop)... That posting of yours doesn't seem to be here
Donal K. Fellows
Bryan Oakley <oak...@channelpoint.com> wrote:
> Well, for inter-application DnD you have a couple of largish hurdles
> to cross. For inter-tcl-application DnD it's fairly doable with send
> (or applescript or the windows equivelent (dde?)). For DnD between
> tcl and non-tcl apps, it's not nearly so cut and dried.
Intra-app DnD is trivial in Tk (and virtually every other toolkit ever
devised) but is a total pain when you try to push it to handle
inter-app stuff. You need communication and data-transfer protocols
(send is just-about acceptable for Tk-Tk on X, but that's about it,)
standardised data formats, fairly standard mechanisms for interaction
with users (this is more important than you might think, IMO,) schemes
to declare that an app will participate in DnD, work to prevent remote
crashes from locking the system, and there are probably additional
issues I've omitted. And it is all incredibly platform-specific.
I'm sincerely hoping that I'm not going to be the person who
implements this for Tk. Even just doing the core[*] part of support
for something like Xdnd <URL: http://www.cco.caltech.edu/~jafl/xdnd/>
is tough. And it would need to be wrapped behind a standard interface
so that the non-X implementations of Tk would work in apparently the
same way too. Aaargh!
Donal.
[* That is adding protocol support without any adaptions to make
existing widgets actually support it. Adding standard versions of
that support is probably about as tough again... ]
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Bryan Oakley
>
> Intra-app DnD is trivial in Tk (and virtually every other toolkit ever
> devised) but is a total pain when you try to push it to handle
> inter-app stuff. You need communication and data-transfer protocols
> (send is just-about acceptable for Tk-Tk on X, but that's about it,)
> standardised data formats, fairly standard mechanisms for interaction
> with users (this is more important than you might think, IMO,) schemes
> to declare that an app will participate in DnD, work to prevent remote
> crashes from locking the system, and there are probably additional
> issues I've omitted. And it is all incredibly platform-specific.
>
> I'm sincerely hoping that I'm not going to be the person who
> implements this for Tk. Even just doing the core[*] part of support
> for something like Xdnd <URL: http://www.cco.caltech.edu/~jafl/xdnd/>
> is tough. And it would need to be wrapped behind a standard interface
> so that the non-X implementations of Tk would work in apparently the
> same way too. Aaargh!
Oddly enough, I was thinking about some sort of cross-platform drag and
drop capability in the shower this morning. I'm funny that way. No
comments from the peanut gallery, please.
I (think I) fully understand the problems with truly getting DnD right
on all platforms. But I don't understand all the problems in supporting
some minimal set. For example, how hard would it be to implement a
virtual binding, say, <<DropFileName>> and <<DragFileName>> that gets
triggered whenever a user drops (or drags) a desktop icon over a tcl
widget?
Nothing more. Just filenames. No automatic feedback or anything else.
Make the application writer worry about that. But this would make it
much easier to write desktop-type applications in tk (file managers and
so forth). Of course, as soon as someone comes up with that, I'd want a
way to be able to initiate a drag of some object within tk that the
system sees as a filename, too (ie: drag an icon of a file from a tk app
to the desktop). But just implementing the former (accepting dropped
filenames from the window manager) would open up a lot of doors. Well,
ok, it would open up one door. But a big door.