On the Mac where I do my programming, I have an app installed called BetterTouchTool that allows me to bind keyboard shortcuts to 'gestures' on my trackpad. I have bound a gesture (that doesn't have an Apple default) to the shortcut command+Q, which quits the active program. I have found this very convenient for quickly quitting programs that I am testing, so that I can get back to writing code.
However for the graphical game that I am programming, this action makes it so that I can't use a three finger swipe to switch between windows (several other gestures are also disabled). This will also happen if I go up to the menu and click quit or if I click the red x close button. The fix is to either restart my computer or (and this is really weird) to click the in-game close button which calls System.exit(0);. I know that most players will be using this but I still want to figure out why this is happening. In addition games like Minecraft on my computer don't do this.
I am using a JFrame with setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); in the code. In an attempt to fix the issue I have tried registering a com.apple.eawt.QuitHandler that calls System.exit(0); in the handler.
I have no idea what would be considered relevant code here, so whatever you would like to see, just let me know.
I figured it out. There was one rouge Thread.sleep() call in my JFrame that was somehow effecting my system.
Related
I want to build a program that does the following:
User clicks on a button (like on a GUI) to record his/hers movements.
Then, the user does a set of actions on the computer - this could be clicking on file explorer and deleting/creating/renaming a file, opening Chrome or another program etc... basically a few keyboard/mouse movements.
Then the user can specify a time at which the program should replicate this recording of movements. (The program hasn't been stopped and it uses the current time of the computer's clock to know when to do it)
Can I do something like this in Java? Searched quite a bit and couldn't see something relevant. The only thing that came to my mind since I am still a beginner is MouseEvents etc but I don't think these can be done outside the frames of GUI.
Thanks in advance I am keen to build this project!
JNativeHook is worth looking into for this and similar purposes. I found it helpful.
https://github.com/kwhat/jnativehook
Java is not my main programming language so my expertise are generally limited in this area.
Scenario
This app is supposed to execute for indefinitely like a service or daemon. Its main purpose is to process some rows in DB as they are inserted by some other process.
The app at times Spits out log messages through System.out.println. It also uses some other log files. I was earlier using log4j but that is disabled for the moment.
Also I am running this in Windows Server environment, if that helps. I cant use linux for now.
Problem
The problem is that, on rare occasions, I find the application in staging/prod env becomes locked or does not seem to process any DB rows further. After I press enter a few times on screen it moves ahead and start processing as usual. This is strange because I am not expecting any input from the user. Any input the app has is either from command line or from DB.
Also I know for sure that its not a DB issue. The app is not waiting for any table lock. It may have to do with some file locking or System.out stream being locked. The later I did not think of possibility until I see that some keystroke on screen 'wakes' the application.
So I am wondering if someone may point me in a direction where I can debug this further.
Microsoft in all its infinite wisdom has made the console window in such a way that it allows you to select a rectangular area of characters with the mouse. So far so good.
And supposedly in order to make it easier for the user to select text while text may be scrolling, they (in their infinite wisdom) freeze the process hosted by the terminal window if it attempts to emit text while you are selecting text. (*)
And it just so happens that if you do as little as click a console window with the mouse, they (in their infinite wisdom) put the window in text selection mode, as witnessed by the presence of a little white square.
Which is very unfortunate, because clicking on a window is what we also do in order to simply bring the window to the foreground. But there is a huge gotcha here: if the console window was not already on the foreground, then clicking it brings it to the foreground. But if the console window was already on the foreground, then clicking it enters selection mode. (And of course most people rarely know, or care, or want to be bothered, with whether the window is already on the foreground or not.)
So, to conclude: try not clicking your window. Click only the caption if you have to. If you do accidentally click on the window, then press [Enter] or click again to make the little white selection rectangle go away.
Because for as long as the little white selection rectangle is there, your program is frozen.
(*) Now, they could have easily frozen the display of the window while selecting without freezing the process; they could have made it so that the output of the process keeps being buffered, and then dumped on the screen once selection is done, but I guess they were too busy with their plans for world domination to get around to fixing this. I cannot even begin to think how much time (= money) must have been wasted all over the world so far due to microsoft console windows sitting idle in selection mode while people are under the impression that they are crunching data.
this is the way to do it
go tp properties and un-check : "quick edit mode"
I am developing a Swing application in Java. The program is to be run on dedicated Windows 7 Touch Screen machines, and as far as I know, this program should be the only thing running on them under normal operation.
I've noticed that Windows 7's touch screen interface has this thing where it will hold back mousedown events. Due to the "tap-and-hold right click" gesture, Windows 7 won't actually send the application a mouse down event until:
the user "touch ups" (raise their finger from a touch, at which point both down and up are sent)
moves their finger (at which point the click becomes a drag)
or the right click circle gesture times out (after about 5-6 seconds)
Trivially, this means that buttons don't look depressed on the application until the mouse down event is sent (and never draw depressed at all with a quick tap). But, recently, more seriously, this means functionality that requires a press-and-hold cannot happen without major amounts of confusion to the average user.
At this point in development it is far too late to turn around and start from scratch with one of the many touch libraries offered on other questions. (They require redoing the entire application in their component hierarchy, and that simply isn't feasible. Plus things coded to use mouse events would then have to be recoded using touch events, and we don't really need multi-touch...)
Yes, I have attempted to simply turn off the touch-and-hold right click gesture. Unfortunately, doing so simply disables the drawing of a circle indicating a right click gesture around your finger and the fire of the subsequent right click. It does NOT remove the underlying problem: the delayed mouse down event for up to six seconds.
My Question: Is there a way to:
Ideally, indicate to Windows that my application is a touch-ready application, so it sends down events immediately (but, I suppose, still send mouse events instead of touch events)? I can see that the built-in soft keyboard works correctly, it seems. I just want my Java application to do the same.
Disable the delay entirely on the computer, but still provide basic touch functionality?
Potentially something as simple as this question, which seems to be asking about the same phenomenon, but in Java?
Typically this type of behavior is controlled by the touch device driver installed on the device. All of the touch manufacturers I have seen have control panel apps that allow you to customize touch behavior. So for instance you can tell the driver to send a mouse click immediately up receipt of a touch rather than delaying briefly in order to prevent an incidental touch from initiating an input event.
Alright so I have a JFrame that I have a KeyListener added to, and I set the focusable equal to true. There is no problem with the KeyListener but it only listens to keys if the window is on top. What I'm trying to do is listen to the key strokes if the window is not on top. Basically, I'm trying to make a program that executes the code when the user presses F10 and stops executing the code when the user presses F10 again. The window shouldn't have to be on top for this program to work, meaning that if I press F10 and the JFrame is not on top, it will still execute. Any help would be greatly appreciated! Thank you.
No, Key Bindings/KeyListeners/any pure Java application will not work as the application must be on top for these to work.
You're looking for a keyboard hook, and Java by itself cannot do this. You'll have to use either JNI, JNA that are linked to a native app such as a C/C++ app, or easier still link Java to a scripting utility such as AutoIt (if Windows, or a similar utility if not). Note that any and all of these solutions must be platform specific.
I am creating an application that is essentially a financial alerts site. I am a basic level Java programmer, and I have created some of the logic for alerts in Java.
I want to be able to have pop-ups appear on the desktop whenever something "interesting" happens (interesting depends on %change, liquidity and a few other simple factors).
What is the best combo of technology to implement something like this?
I would use the java.awt.SystemTray in Java SE 6. It's cross-platform and pretty easy to use.
Although some people hate the balloon notifications in Windows, they're the least obtrusive popups, since they can be ignored by the user or easily dismissed. Most importantly, they can't be missed by the user who has been away from the computer, because balloons (at least in Windows XP/Vista) use system idle timers to determine when's the right time to disappear.
Some prefer more traditional toast notifications, similar to those shown by Outlook - they show up and slowly fade out, giving the user some time to interact with them if needed.
I had the same problem and finally solved it using an undecorated, alwaysOnTop window.
And thanks to this blog entry I found the TimingFramework, and now it even is translucent, fades in and out, goes 100% opaque on mouse over etc. In conjunction with the SystemTray and TrayIcon the behavior is nearly as that of Outlook.
Oh, I have to note, that other than the second link, I do the fading out with
AWTUtilities.setWindowOpacity(window, op);
You could write a java program that resides in the system tray, but I am not sure if there are cross platform compatible ways to do this. maybe you have to use a platform specific library for Win, Mac, Linux, ...
I'd just create a message window and animate it. Then add SystemTray support and voila, you're done.
In Delphi you can do that pretty quickly, but you can't easily reuse your java logic
You can just run you program in "silent" mode, without creating any windows by default, maybe just a little icon in the taskbar which when double-clicked will open a settings window. The program will be running in the background and creating windows with the set focus whenever an event happens.
But in my opinion, a slide window or at least a balloon tooltip is a better idea.