I wrote an applet, which needs to receive mouse events from the user. The problem is - it works for all other browsers, but in Opera it receives only mouse wheel events and mouse pressed/clicked events.
And so I am not able to get the location of the mouse on the component.
It's clearly an Opera bug because sometimes it magically starts working (without any changes to my app), then after a reload it stops working.
So the question is - have you encountered this problem, and is there a way to solve it?
Opera here. Is this limited to a particular operating system? Do you have some sample code or demo? You're missing mousemove, x, y etc.? We are currently improving this area so would be good to know if we already fixed this or not.
Related
In this page the CheerpJ conversion of the applet in this page (with identical byte-code) does not seem to recognize mouse dragging past the applet frame boundary. It would be nice if that were possible.
Is this just a problem with my client-side setup (Linux Debian 9.2), or do others see the same behvior?
What is very strange, is that the original behavior is converted correctly on the not-supported-by-CheerpJ iphone browsers (I have checked safari and firefox there). Could investigation of this fact help CheerpJ developers understand how to make the MouseMotionListener interface recognize mouse dragging anywhere on the screen, not just within the applet frame?
Maybe this is impossible, but I thought it was worth asking.
Edit: Changed title to be less negative about CheerpJ (which overall I find almost too cool to be true!) and more reflective of actual the question.
The mouseDragged method is correctly implemented to the best of our understanding. The Java event is derived from the mousemove JavaScript event which is not delivered when the mouse is outside of the applet surface. With the legacy plugin applets are displayed on native windows which have different behavior.
It could be possible that using different JavaScript events, like mousedrag would make CheerpJ behavior more similar to native, but reworking this without causing regressions would require significant work and it is not currently a priority for us. Especially considering that our customers normally have full screen Swing applets which cannot exhibit the problem
On mobile devices the touchmove event is used, which is probably what causes the difference you see.
If you want to report a bug you can do it here: https://github.com/leaningtech/cheerpj-meta/issues
Ok, so this is a really, REALLY weird issue that we're having with the application at my company. I'm going to try and describe this as best I can.
First, this is a legacy application with a Swing UI.
Second, the issue only occurs when it is compiled & run using Java 8. With Java 7 and below, this does not occur.
So, the issue: When a dialog is displayed (modal or non-modal, doesn't matter), the UI becomes unresponsive to mouse clicks. What's truly crazy, though, is the UI is NOT frozen. Hovering the mouse over something produces the hover highlight as normal. Keyboard commands are received perfectly. Mouse clicks, however, do not work.
This also only occurs on OSX. Windows and Linux don't have this problem. I'm running this on OSX El Capitan.
As far as code samples, it's affecting all dialogs across the application. JOptionPanes & JDialogs, doesn't seem to matter. Here's a simple JOptionPane declaration:
int n = JOptionPane.showOptionDialog(mcContext.getMapperView(), "xPath of dropping target can't be evaluated" +
"\nPlease, select xPath for dropped node",
"xPath calculation for dropped node",
JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.QUESTION_MESSAGE, null, options, options[0]);
This code IS being called on the EventThread, so I don't believe it's a threading issue.
I'm totally stumped as to the cause of this. So far we've ignored it by compiling and running it in Java 7, but at some point as versions progress we will need to deal with this issue more directly.
Anyone have any ideas?
Edit: Thanks for the SSCCE Idea. Now I'm more confused than ever. When I put together a quick frame/dialog demonstration, it worked perfectly. No issues. So I don't know what it is in the application that could be causing this. Any good places to start looking?
Edit 2: Wrapped one of the declarations in SwingUtilities.invokeLater, and it worked. Ok... now what could the culprit be? It's still got to be something that Java 8 is compiling different than Java 7.
Edit 3: More weird behavior. I moved my IDE into a separate "desktop" than the application it was running, and when the buggy dialog is displayed, i cant switch to that desktop. I can switch to any app on the current desktop, but not to another desktop.
Edit 4: The dialogs in question are being triggered by drag and drop actions. Not sure if that helps or not, but I do see that there is a thread in the background in the thread dump using the sun.lwawt.macosx.CDragSourceContextPeer class.
Alright, it took a while, but I think I found it. I found an OpenJDK post that seemed to very clearly describe this issue.
https://bugs.openjdk.java.net/browse/JDK-8139393
Somehow, Drag N Drop in Swing on OSX in java 8 isn't releasing its hold on the MouseEvent or Listener, so when a modal dialog is displayed the mouse isn't able to get new events through to it. Which is a crazy stupid bug, but it's there.
The solution was wrapping my code in SwingUtilities.invokeLater(...). By having the code that displays the dialogs executed asynchronously from the drag and drop code, the drag and drop operation is able to complete and release its hold on the mouse connectivity (for lack of a better description). And viola! Problem solved.
Thanks to everyone who tried to help. Hope this post helps out anyone else dealing with this issue.
On an Android platform I have to find out the global mouse position. This means not just in the currently running app. But in any app or in home screen. I have full access to the Android platform. So this could be also some solution in C working on the underlying Linux system.
I know its pretty easy on Linux using xdotool, but unfortunately this relies on Xlib and so on. There is no X server on Android. At least not on mine.
Is there some command I can use or something on the Linux system, where I can read the mouse position?
Thanks,
Eduard
I couldnt find a way to get the mouse position. So I have implemented a workaround to control the mouse with absolute values. Im resetting the mouse at start to 0/0 and after that Im buffering the actual position.
AutoIt seems to stop working when focus is given to a java application.
For this code:
MouseMove(61, 121, 10);
WinActivate("Main # paperMoney [build 1800.20]");
MsgBox(0, "got it", "got it");
Results are --> Mouse moves, java application gets focus and message appears
For this code:
WinActivate("Main # paperMoney [build 1800.20]");
MouseMove(61, 121, 10);
MsgBox(0, "got it", "got it");
Results are --> java application gets focus, mouse DOES NOT move and message appears.
Is there anything I can do to make the mouse and keyboard commands work after the java application has focus?
Considering what paperMoney does, it is probably purposely resisting automation. Especially when the Window is activated, it will hook into low-level mouse events and check all hardware mouse movement with actual movement. Using that it will prevent any simulated mouse movement. Can you use Send to type keys in the Window?
I looked to do the same thing. Mandanar is probably right. I also tried Autohotkey with no success. Perhaps TOS is prohibititng it deep in their application. :( Boo!
EDIT:
Some playing around I've discovered that TOS on Mac OSX can be controlled via scripting with Keyboard Maestro. It's a ugly, hacked solution, but it works. You can edit text boxes and click stuff if you know the X,Y position of elements.
Keyboard Maestro can be run via scrips (AppleScript, Python, etc.) so maybe you can build some elaborate rube goldberg.
Happy trading!
My solution was tested for AutoHotkey, but I believe this should work for AutoIt also. I ran the script with administrator privileges since TOS is ran as an administrator and my scripts work fine after that.
I'm trying to find a concrete yes for some assumptions I have about developing a Java Swing app to be run on a Windows tablet device (I believe it'll be running Windows XP). We have a demo we are writing and we're leveraging previous experience with Java Swing to write the UI and I just want to make sure that touch events in Windows are treated like mouse clicks, is this true? Does anyone have any direct experience writing Swing apps for Windows tablets? The target device is http://www.amazon.com/Promotion-X70EX-3GP-Accessory-Standard/dp/B002MZZX76.
Also, wondering if the soft keyboard will automatically be activated when focus is given to a JTextField and other Swing data entry fields.
Thanks!
We developed an application in Swing which runs well on Windows XP tablets. Yes, touches are treated just like mouse clicks. However, I can only confirm this for basic touch events, e.g. clicking on a button. I can neither confirm nor deny whether they work for more complex gestures.
As for the soft keyboard, I cannot remember whether this works or not. In the end our users ended up using the tablet just like a regular laptop, i.e. with the keyboard not the touch screen. This is mostly due to the amount of text they need to enter in the application.