-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
1.1.4, 1.2.0, 1.2.1
-
generic, x86
-
generic, windows_95
Name: vi73552 Date: 03/09/99
please allow for slight movement to occur while the user presses
a mouse button to still deliver a mouseClicked() event (and NOT
a mouseDragged() event).
as it stands, only mousePressed(), mouseDragged() and mouseReleased() events are sent even if the mouse moves even
one pixel during the actual pressing of a button. this is
a very common occurance judging by how many complaints we
get from our customers about this problem.
this behavior seems to be on win32 jdk only - i believe you may
have in fact added a fix for this on solaris already...
other windows apps handle this smudge factor appropriately,
but java apps do not.
(Review ID: 53202)
======================================================================
Name: vi73552 Date: 05/14/99
Build the following program:
-----------------------------------------------------------------
import java.awt.*;
import java.awt.event.*;
public class Click
{
static int nClicks = 0;
static int nReleases = 0;
static int nCloseCalls = 0;
final static int THRESHOLD = 3;
public static void main(String args[])
{
Click c = new Click();
c.main();
}
public void main()
{
TestFrame f = new TestFrame("Click me");
f.addMouseListener(new MouseAdapter() {
int x0 = -100;
int y0 = -100;;
public void mouseClicked(MouseEvent e)
{
nClicks++;
}
public void mousePressed(MouseEvent e) {
x0 = e.getX();
y0 = e.getY();
}
public void mouseReleased(MouseEvent e) {
nReleases++;
int xDiff = Math.abs(x0-e.getX());
int yDiff = Math.abs(y0-e.getY());
if (xDiff <= THRESHOLD && yDiff <= THRESHOLD) {
if (xDiff > 0 || yDiff > 0) {
nCloseCalls++;
}
}
}
});
f.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.out.println("Actual clicks: " + nReleases);
System.out.println("Clicks registered: " + nClicks);
System.out.println("Close calls: " + nCloseCalls);
System.out.println("Clicks missed: " + (nReleases - nClicks));
System.exit(0);
}
});
f.pack();
f.setSize(new Dimension(640, 480));
f.setVisible(true);
}
public class TestFrame extends Frame
{
public TestFrame(String s)
{
super(s);
}
public void paint(Graphics g)
{
int w = getSize().width;
int h = getSize().height;
g.setColor(Color.black);
for (int y=0; y<h; y+=h/10) {
g.drawLine(0, y, w-1, y);
}
for (int x=0; x<w; x+=w/10) {
g.drawLine(x, 0, x, h-1);
}
}
}
}
-----------------------------------------------------------------
Run the program, and move the mouse around the window that
appears, making a couple dozen mouse clicks. (E.g., try clicking
on several of the drawn squares.) Close the window and look at
the displayed statistics:
The number of times that the mouseClicked method of the mouse
listener was called is smaller than the actual number of clicks,
which is correctly printed as the number of mouse releases.
Also note that the number of "close calls", i.e., the number
of mouse releases that were very close to, but not exactly on
the point where the mouse was pressed, is almost identical to the
number of unregistered clicks.
What I'm trying to say here is that the AWT is very unforgiving
in what it considers a mouse click, as it does not allow for
any shakiness of the hand or any mouse skid when the mouse
button is pressed.
What this means in terms of real applications is that if mouse
clicks are detected using mouseClicked, it appears to the user
that many clicks do not register.
Output of "java -version":
Windows:
java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads)
Solaris:
java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads, sunwjit)
Output of "java -fullversion:"
Windows:
JAVA.EXE full version "JDK-1.2.1-A"
Solaris:
java full version "JDK-1.2.1-A"
This bug also exists in version 1.1.
(Review ID: 63198)
======================================================================
- duplicates
-
JDK-4094664 Allow DBL-clicks to be detected within a "tolerance" between two successive pts.
-
- Closed
-