Java AWT Window management, user input, and focus? - java

I'm trying to hunt down the source of a bug that relates to window management, and possibly awt specifically. However, I have little to no familiarity with window management in general, or awt, so I'm even sure what I searching for. I'm hoping for some general guidance on terminology or otherwise that might help guide me in the correct direction.
In the program I am working on, the user can open windows that can be interacted with (i.e. they have text input boxes, drop down menus, etc) and windows that cannot be interacted with (i.e. they just display dialog). When the user opens a "non-interactive" window, the user can still use the underlying program. However, when an "interactive" window is opened, the user is blocked from using the underlying program until the window is closed. Additionally, "interactive" windows seem to stack themselves on top of "non-interactive" windows. That is to say, if I open a "non-interactive" window and then open an "interactive" window after, the "interactive" window will place itself on top of the "non-interactive" window and won't allow the user to use any of the title bar widgets. In this program, this behavior is not always desirable.
I assumed that this would have something to do with focusing, but I read through this document without much luck (this could be that I just don't know what I'm looking for). Particularly, I noticed the mention of "VetoableChangeLister" which doesn't seem to appear anywhere in the code I'm working with, as well as the method "requestFocusInWindow", which does appear in the code I'm working with but not in any way that I could see that relates to my above problem description.
Would the above problem be related to window focusing? Or am I barking up the wrong tree here? If nothing else, even some basic terminology so I can at least Google search intelligently.

The question I was asking relates to the "modality" of windows and was answered in the comments. The link provided explaining modality is https://docs.oracle.com/javase/tutorial/uiswing/misc/modality.html

Related

How to make sure the user does not able to do any other thing once my window is shown in linux/mac [duplicate]

How can I disable OS-level keyboard shortcuts (e.g. Alt-Tab, Ctrl-Alt-Left/Right, etc.) on a [Ubuntu] Linux machine? I'm developing a full-screen Java Swing app and don't want the user to be able to task switch away from the program arbitrarily. It's not enough to toggle the "always on top" flag; users mustn't be allowed to switch workspaces, migrate focus or any other such things. The machine must function normally before and after the application is executed. Google says that this will require JNI or JNA but I'm looking for a bit more hand-holding.
There's no point in trying to do this in your application because any of these changes are going to need to be handled by X11 and/or the window manager since those are what respond to the commands. Assuming that you have control of the platform, choose a window manager which supports a kiosk mode. Then use the window manager's settings to start your application and enter kiosk mode.
Options for window managers which can do this include KDE or twm-kiosk.
(And if you don't have control of the platform, you're not likely to be able to have your application intercept things like ctrl-alt-backspace anyway.)
Edit:
In response to a scaled-down version of the question in which he's willing to let things like ctl-alt-backspace go and just wants most of the keys including alt-tab or other similar application switching key combinations, the following should work:
You should be able to do this using XLib's XGrabKeyboard method through JNI. This Java/XLib JNI keypress capture tutorial should be a good starting point. However, it uses XGrabKey which just passively listens for keys and does not prevent other applications from receiving them. You'll instead want to use XGrabKeyboard which actively snags all of the normal keyboard events (which, if the premise of this StackOverflow question is correct, includes the task switching keys).
Note that as a side-effect, key capture in Swing will also probably stop working because your Swing windows are going to be separate from the window you create in C. As such, you will probably have to use your JNI interface to get key presses to your program when needed. (Although I would definitely advise testing it first before writing the code.) You might be able to avoid this if you can get the window using Java AWT Native Interface to get the window ID. (Note that Swing is built on top of AWT, so this will work for Swing.) However, I'm not sure how to do this. It looks like you might be able to navigate the window tree by getting the root window from the Display and going from there to find your Window, but it's all kind of weird. It would be nice if the AWT NI just told you the window ID, but it doesn't look like it does that.
As this warning Reminder: XGrabKeyboard is not a security interface notes, this doesn't make it impossible for other programs to see the keys, but it seems likely that window managers will not be using XQueryKeyMap so it is likely to prevent task switching.

Exclamation point in top right of windows - over the close button

When I open some Java applications, especially examples launched from Java Web Start, I will often see an exclamation mark next to/covering the close button, depending on the window size. It is a bit worrying actually.
What does it mean, and what is its function?
It means the app. is sand-boxed.
The function of it is to inform the user that an app. is running that is sand-boxed.
See Exploring Security Warning Functionality for more details.
It is supposed to be a bit worrying, actually. Don't go typing your bank account details into one of those floating windows that looks 'something like' your bank log-on. ;)

Java 5 - Bring Modal Dialog to Front on any click

Setting: Java 5 - no upgrade possible.
I have a large application that has a number of modal dialog windows. I have heard that hidden modal dialogs can result in uninformed users going so far as to restart their computer. Even if a user knows how to ALT-TAB (in MS Windows, at least), it's a pain. From what I understand, this was in part fixed in later versions of Java, but that's not an option here, unfortunately.
So, is there any way to force a modal dialog to be shown if any part of the running application is clicked on? I was thinking it might have something to do with either MouseListeners, GlassPanes, or something else. However, I've got a bunch of other stuff I'm supposed to be working on, so I don't have a lot of time to devote to hashing this out right now. Can anybody point me in the right direction?
Thanks so much!
So, is there any way to force a modal dialog to be shown if any part of the running application is clicked on?
When you create the dialog you need to specify the parent frame as the owner of the dialog. Then whenever you click on the frame any dialog that is a child will also be shown.

WM_PAINT, Java and capturing hidden windows

First a disclaimer, I'm a Java programmer and have almost no idea about the Windows API. So please bear with me.
My goal is to use Java to capture a hidden window. My target platform is Windows. I do understand that the Robot class is used for capuring the visible part of the screen. After some browsing, I came across these three links, which seem to be relevant:
http://www.support.teamdev.com/thread/1930
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.ui/2006-02/msg00204.html
http://www.fengyuan.com/article/wmprint.html
JxCapture is as bloodily expensive as Feng Yuan article is complicated. My question is this, if the gurus in this forum can help me find a reasonable solution. The approach suggested in JxCapture does not seem to be overly complex. Any hints? A visual basic script or some C# code that does this would be a good starting point.
I was of the belief that when the window is hidden, if I send a keypress event or a mouse press event to it, it would force it to redraw itself and hence allow itself to be captured even by java.awt.Robot. That was an illusion and it doesn't work.
On the other hand, the message in the JxCapture thread is from the year 2006; could it be that Sun has included such a feature since then and I'm just not aware of it?

Screen capturing inactive window

Is it possible to get image contents of an obstructed window without bringing it to the front? Also, is it possible to send mouse clicks to a specific locations of such window? I want to do this in Java, using JNA, running Windows XP (if it is possible, would it also work on Windows 7?). If that can be done, would you mind telling me what functions will be needed and where can I read about it, because I have never worked with JNA yet. Thank you.

Categories

Resources