mouseClicked vs. mousePressed on Apple vs. Windows

java-programmer, mouseClicked vs. mousePressed on Apple vs. Windows I'm writing a Swing component which must function similarly on Apple
and Windows; and am having trouble with which event to fire off of
(this is effectively a toggle button which would ideally just be
interested in mouseClicked). For a variety of other reasons, I don't
want to make my code act on the mousePressed event.

Originally, our QA person asserted that it was busted because she was
clicking (and moving the mouse > 10 pixels) and it wasn't getting
"toggled" (this was on Windows). I won the battle there by saying
"don't move it 10 pixels; that's a drag, not a click". (after
debugging and figuring out that if you moved the mouse more than
approximately that much, the mouseClicked never came in).

However, she now claims that on Apple (OSX) that the button fails to
toggle if you move the mouse even one pixel while pressing the button.
(i.e. if you are not perfectly still while clicking).

Obviously this would be a different story. I don't have immediate
access to an Apple machine, so was wondering if anybody else had seen
this behavior. When I worked on the AWT on OS/2 at IBM, it was fairly
clear that the mouse events were determined based on native operating
system events (i.e. when Windows says it is a click, we'll say it is a
click). Don't know if that's true now or not, since I haven't seen the
code since Java 1.1.8.

---
Mike Dahmus
m dah mus @ at @ io.com

java-programmer >> mouseClicked vs. mousePressed on Apple vs. Windows

Mike Dahmus wrote:
>
> I'm writing a Swing component which must function similarly on Apple
> and Windows; and am having trouble with which event to fire off of
> (this is effectively a toggle button which would ideally just be
> interested in mouseClicked). For a variety of other reasons, I don't
> want to make my code act on the mousePressed event.
>
> Originally, our QA person asserted that it was busted because she was
> clicking (and moving the mouse > 10 pixels) and it wasn't getting
> "toggled" (this was on Windows). I won the battle there by saying
> "don't move it 10 pixels; that's a drag, not a click". (after
> debugging and figuring out that if you moved the mouse more than
> approximately that much, the mouseClicked never came in).
>
> However, she now claims that on Apple (OSX) that the button fails to
> toggle if you move the mouse even one pixel while pressing the button.
> (i.e. if you are not perfectly still while clicking).
>
> Obviously this would be a different story. I don't have immediate
> access to an Apple machine, so was wondering if anybody else had seen
> this behavior. When I worked on the AWT on OS/2 at IBM, it was fairly
> clear that the mouse events were determined based on native operating
> system events (i.e. when Windows says it is a click, we'll say it is a
> click). Don't know if that's true now or not, since I haven't seen the
> code since Java 1.1.8.
>
> ---
> Mike Dahmus
> m dah mus @ at @ io.com

A click is usually defined as pressing and releasing the mouse button
without moving in between.

I never use the MouseClick, since it is very difficult for some people
to do this.

This is especially true for buttons (push buttons or toggle buttons) -
you usually want to give the user the opportunity to change her mind
after pressing the button, so she could move away from the button before
the release and thus have no action taken.
--
Fred L. Kleinschmidt
Associate Technical Fellow
Boeing Common User Interface Services

java-programmer >> mouseClicked vs. mousePressed on Apple vs. Windows Mike Dahmus wrote:
> I'm writing a Swing component which must function similarly on Apple
> and Windows; and am having trouble with which event to fire off of
> (this is effectively a toggle button which would ideally just be
> interested in mouseClicked). For a variety of other reasons, I don't
> want to make my code act on the mousePressed event.

You might not want to be hooking mouse events of any kind. Would it not
be sufficient to extend javax.swing.AbstractButton or
javax.swing.JToggleButton and hook action events? Or is that what
you're doing now that isn't working well? Similar cross-platform
behavior will be easier to achieve the higher the level at which you
work. Indeed, depending on your exact requirements you might do even
better by using a concrete JToggleButton implementation and installing a
custom look and feel.

John Bollinger
email***@***.com

java-programmer >> mouseClicked vs. mousePressed on Apple vs. Windows On Fri, 29 Aug 2003 10:56:13 -0500, Mike Dahmus
<email***@***.com> wrote:

>I'm writing a Swing component which must function similarly on Apple
>and Windows; and am having trouble with which event to fire off of
>(this is effectively a toggle button which would ideally just be
>interested in mouseClicked). For a variety of other reasons, I don't
>want to make my code act on the mousePressed event.
>
>Originally, our QA person asserted that it was busted because she was
>clicking (and moving the mouse > 10 pixels) and it wasn't getting
>"toggled" (this was on Windows). I won the battle there by saying
>"don't move it 10 pixels; that's a drag, not a click". (after
>debugging and figuring out that if you moved the mouse more than
>approximately that much, the mouseClicked never came in).
>
>However, she now claims that on Apple (OSX) that the button fails to
>toggle if you move the mouse even one pixel while pressing the button.
>(i.e. if you are not perfectly still while clicking).
>
>Obviously this would be a different story. I don't have immediate
>access to an Apple machine, so was wondering if anybody else had seen
>this behavior. When I worked on the AWT on OS/2 at IBM, it was fairly
>clear that the mouse events were determined based on native operating
>system events (i.e. when Windows says it is a click, we'll say it is a
>click). Don't know if that's true now or not, since I haven't seen the
>code since Java 1.1.8.

Following up:

A colleague of mine wrote a simple test case and confirmed the
different behavior on Apple vs. Windows. Ended up rewriting my code to
do something similar to what AbstractButton does (remember where the
mousePressed happened; then on mouseExited or mouseReleased, process
accordingly).

---
Mike Dahmus
m dah mus @ at @ io.com