java - get mouse events outside of a component - java

i'm having the same issue as the person here, in that i need to track a frame location while it is being dragged on OS X. The question had not been resolved there, so:
how do i tell a frame that a mouse down event happened on its (OS-native) title bar or, more generally, that a mouse down event happened somewhere on the screen?

Since java 1.5
import java.awt.MouseInfo;
public class Mouse {
public static void main(String[] args) {
while ( true ) {
System.out.println( MouseInfo.getPointerInfo().getLocation() );
}
}
}
EDIT:
Native keyboard mouse hook
http://www.jotschi.de/?p=90

Using pure Java, you can never tell that a mouse down event happened on its (OS-native) title bar, or for that case any event outside you application window(excluding title bars).
It's important understand that as a programmer in AWT/Swing your context and realm and power lies only within the application window.
Best shot is to use JNI.

Related

Interface management eclipse

I al reading a code that I did not create and I have some trouble to understand how it is working and especially how action event ( like a click) are managed ?
So far I am undertanding that it creates a the first window will all buttons and boxes and the main end with a setVisible(true); and my window appears.
Then is ask my some file locations and I click on a button to go to the second window.
What I would like to understand it is how in java we managed this click event for the second action ? I mean I understand the use of button addActionListener the first time but my understanding ends with the second event (=I click on the button and it brings me to the second window and do the calculation) i.e. where/ how in the code this is handle and goes a scond time to the functions.
Knowing that at the end of the main I have some functions starting with
InterfaceDynamics.cardSwitch() and this function managed all events that can occur
public static void cardSwitch(final String _buttonKey, final String _Key, final JPanel _cardPanel,
Another related question (I guess related) it is the use of
EventQueue.invokeLater(new Runnable() {
#Override
public void run() {
new Main();
which I really do not undertand (even if I already google it).
Sorry if I am not clear and for my bad understanding of java and window, Swing, Frame management and really thanks for any help.
Regards

JList - locationToIndex() always returning the same index for mouse location in thread

I'm testing around a bit with JLists and I wanted a little window to pop up on MouseEnter and show the content of the list entry the mouse was hovering over; also the window disposes on MouseExit.
So far this worked great, but for it to update the mouse has to exit and re-enter.
Now I wanted to make it work in a parallel Thread and update the window all the time, so it would change without me having to exit first, and tried this:
public void run() {
while (!Thread.interrupted()) {
Point p = MouseInfo.getPointerInfo().getLocation();
String text = list.getModel().getElementAt(
list.locationToIndex(p));
lab.setText(text);
}
But it always only shows the content of the last entry in the list, no matter where the mouse is.
If I print out textit's always the same content, even though the mouse position changes.
What am I doing wrong?
MouseInfo.getPointerInfo().getLocation() gives the location of the mouse within the context of the screen.
JList#locationToIndex expects the point to be within the context of the JList.
This can be a little confusing at first, but, basically, when dealing with functionality like this, components except the point to be within their coordinate context, where 0x0 is the top, left corner of the component. This actually makes life a lot easier, as you don't constantly need to be translating between screen and component coordinates...
You will need to first convert the Point to component coordinates...
SwingUtilities.convertPointFromScreen(p, list);
Then request the index of represented by the point
Also note that Swing is not thread safe, that means that you should only ever access or modify UI components from within the context of the Event Dispatching Thread.
So this makes...
String text = list.getModel().getElementAt(
list.locationToIndex(p));
lab.setText(text);
...very dangerous.
See Concurrency in Swing for more details
Without knowning exactly what you're trying to do it's difficult to provide alternative suggestions, but you might consider using a MouseListener and/or MouseMotionListener, registered to the JList, instead
The immediate benefit of this is that the MouseEvent is already converted to the coordinate space of the component that triggered the event
Use this code instead yours code
Point p = MouseInfo.getPointerInfo().getLocation();
list.setSelectedIndex(list.locationToIndex(p));
String text = list.getSelectedValue().toString();
lab.setText(text);
private void JLISTE_clicked(java.awt.event.MouseEvent evt) {
if (SwingUtilities.isRightMouseButton(evt)){
if (evt.getComponent()==JLISTE){
int idx = JLISTE.locationToIndex(evt.getPoint());
System.out.println("Index rightclicked : " + idx); // testing
JLISTE.setSelectedIndex(idx);
}
}
....
}

Java Mouse Listener

This probably sounds simple and stupid, but for the life of me I cannot find a way to have a mouse listener which does mousePressed without having to be on a component. void mousePressed(){} doesn't seem to work the way I want it to.
Essentially I am making a java program which aims to work without graphics, and does things in the background. So if you click in chrome for example it still will effect the program.
What I was trying was this, which I realize is horribly incorrect.
class MKeyListener extends KeyAdapter {
#Override
public void keyPressed(KeyEvent e) {
moveMouse.playing = false;
}
}
As reccomended I tried the JNativeHook library, however it doesn't seem to work the way I think it should:
public class mousepresstest implements NativeMouseInputListener{
#Override
public void nativeMouseClicked(NativeMouseEvent e) {
System.out.println("worked");
}
}
It doesn't print the text on mouse pressed, am I missing something here?
Java Mouse listeners are only meant for swing/awt components and that too from the same running process.
If you want to listen for mouse/keyboard events from other apps use the JNativeHook
library.You can install a global keyboard hook and listen for keypress or a mousehook for mouse events.You do not need to use Swing or other GUI classes.
Internally JNativeHook uses JNI to provide these functionality.

ALWAYS on top window

I'm searching for a solution in order to keep a JFrame always on top and with always I really mean always.
setAlwaysOnTop( true );
This won't work when I'm starting a game in fullscreen mode. I know you normally don't want your windows to stay on top but in this case it's required.
This can't be done.
For example, the Windows Task Manager, even when set to Always on Top will get covered up by full-screen applications.
This is due to the fact that full-screen applications typically use a different graphics context and can't be overlayed.
Start another process to check if the window is on top,if not, set it on top.
This is a sample code that should be helpful
public class AllWaysOnTop extends JFrame implements WindowListener {
AllWaysOnTop() {
// Code to setup your frame
addWindowListener(this);
// Code to show your frame
}
// The window event handlers. We use WindowDeactivated to
// try and keep the splash screen on top. Usually only keeps
// the splash screen on top of our own java windows.
public void windowOpened(WindowEvent event){};
public void windowActivated(WindowEvent event){};
public void windowDeactivated(WindowEvent event){
toFront();
}
public void windowIconified(WindowEvent event){};
public void windowDeiconified(WindowEvent event){};
public void windowClosed(WindowEvent event){};
public void windowClosing(WindowEvent event) {};
}
Reference
This forum post
This sounds like the kind of question that Raymond Chen always has to answer over at Link. How can you really really forever and for true keep a window in the foreground? You can't. Because what happens if somebody ELSE's window uses the same trick to keep itself always always and forever in the foreground? Which one wins?
If you mean fullscreen as in DirectX/OpenGL/whatever, I'm not sure you can (or should) really pull it off. Most operating systems disable their native windowing during full screen to improve rendering performance. Swing works via the native windowing toolkit.
You could write something that uses a timer and in short intervals (e.g., 200ms) instructs your window to go to the top. Depending on your operating system this would be exactly what you need, or a horrible cause of performance trouble or flickering.
I'm not sure but i would bet that the Fullscreen window also has Always On Top set to true, and in that case you have stumbled into the realm of undefined behavior. In general when two windows are set to always on top there is no guarantee about ordering. I think in general though the order is just dependent on the order in which they were set to always on top. So in that case i would just wait until the app has gone fullscreen to set it to always on top and see if that works.
In other cases ive seen people start threads and then occasionally reset the fram to always on top.
All these solutions are ugly, so just use the one that lets you sleep at night.
I know this post is old, but I encountered this problem and I found a satisfying solution.
My program has some notifications that I wish to be always on top, but when a movie entered full-screen, they disappeared. Fortunate, my program updates these notifications every 5 seconds, and if I call setVisible(true) on these JWindows, at each update, they regain the top position, if they have lost it.
I was looking to do the same thing as OP, have my app running in the foreground while my game ran. It doesn't work in fullscreen but if you put the game into windowed mode and adjust the window settings to fit your tv it works. I only needed the frame.setAlwaysOnTop to make it work.

java Swing debugging headaches with Wacom pen tablet

I've been running up against a problem with Java Swing + my Wacom Graphire tablet for a few years in several Java applications and have now encountered it in my own.
I use a pen tablet to get around wrist issues while clicking a mouse, and it works fine under Windows except when I'm using Java applications. In Java applications, the single-click of the pen doesn't work correctly. (Usually the problem only occurs with file-selection dialog boxes or tree controls.) The pen tablet also comes with a wireless mouse that works with the same tablet, and its single-click does work correctly.
I don't know whether the problem is in the WACOM driver or in the Java Swing runtime for Windows or both. Has anyone encountered this before? I'd like to file a bug report with WACOM but I have no idea what to tell them.
I have been able to reproduce this in my own application that has a JEditorPane with an HTML document that I've added a HyperlinkListener to. I get HyperlinkEvent.ACTIVATED events on every single click with the mouse, but I do NOT get HyperlinkEvent.ACTIVATED events on every single click with the pen.
One big difference between a pen and a mouse is that when you click a button on a mouse, it's really easy to cause the button-click without mouse movement. On the pen tablet it is very hard to do this, and that seems to correlate with the lack of HyperlinkEvent.ACTIVATED events -- if I am very careful not to move the pen position when I tap the tablet, I think I can get ACTIVATED events.
Any suggestions for things to try so I can give WACOM some good information on this bug? It's really frustrating to not be able to use my pen with Java apps, especially since the pen works fine with "regular" Windows (non-Java) applications.
Normally I wouldn't ask this question here but I'd like to find out from a programmer's standpoint what might be going on so I can file a good bug report.
What you should do is add a mouseListener and see when it registers a mouseClicked(), mousePressed(), mouseReleased() event. I'm not sure if the swing reads the tablet pen as a mouse though. However, it should give you some insight into what's actually going on.
I tried dr.manhattan's suggestion and it works like a charm. I get mousePressed/mouseReleased events correctly; mouseClicked events happen always with the pen tablet mouse, but mouseClicked events do not happen with the pen unless I manage to keep the pen very still. Even a 1-pixel movement is enough to make it fail. I guess I should blame Java for this one: there's no way to specify a "click radius" for acceptible movement.
package com.example.bugs;
import java.awt.Dimension;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;
import javax.swing.JFrame;
public class WacomMouseClickBug {
public static void main(String[] args) {
JFrame jframe = new JFrame();
jframe.addMouseListener(new MouseListener(){
#Override public void mouseClicked(MouseEvent event) {
System.out.println("mouseClicked: "+event);
}
#Override public void mouseEntered(MouseEvent event) {}
#Override public void mouseExited(MouseEvent event) {}
#Override public void mousePressed(MouseEvent event) {
System.out.println("mousePressed: "+event);
}
#Override public void mouseReleased(MouseEvent event) {
System.out.println("mouseReleased: "+event);
}
});
jframe.setPreferredSize(new Dimension(400,400));
jframe.pack();
jframe.setLocationRelativeTo(null);
jframe.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
jframe.setVisible(true);
}
}
I think you already got the answer yourself: Moving the pen results in some other event than a simple click, perhaps maybe a Drag and drop like event.
I'm not sure whether it's a Java/Swing or a Wacom problem, it could be that the tablet doesn't register the clicks as such but as drag events, or it could be that swing interprets the events incorrectly.
I reported this bug many years ago to Sun. It still is not fixed. Any decent ui framework will allow some movement between a press and release to generate a click event. A maximum movement of 1 pixel on a high dpi display is just ridiculous. It is not only an issue with wacom tablets, ie older people also have difficulties to keep the mouse still when clicking.

Categories

Resources