I want to understand how java.awt.Dialog achieves modality (blocking other windows)?
Yeah, I tried reading the code of java.awt.Dialog, but I am kind of getting lost in it. So I want to know briefly what they do. Do they disable all events of all other windows?
Thanks
Prem
Its system dependent. On windows the main event loop is modified. You are most of the time better off opening a dialog non-modal and lock the underlying window manually (e.g. set a glasspane to the rootpane and disable it, or block all events setting a custom focus manager).
Related
Is there a possibility to prevent a JOptionPane dialog from blocking the interaction with the rest of the program, especially child JFrames? In my GUI, I launch a JFrame and want a message dialog to pop up after the child is closed to remind the user of something, but they launch parallel and the reminder blocks the child frame from being used.
Like here:
popupObjMan newPopup1 = new popupObjMan(gatewayAbstract, gatewayAbstractID);
JOptionPane.showInternalMessageDialog(this, "REMINDER: DO REFRESH");
I've tried to set the popup always on top, but this doesn't quite do the job.
I have no problem with them launching parallel (I'd even prefer it), but I could not work my head around it yet.
I just started Java programming ,so sorry in case that'd be something obvious.
A JOptionPane normally need to be modal. It shows something important and waits till the user answers with whatever option you give him (e.g. ok-button, yes/no-buttons, ...)
But there are several ways to reach your target.
(a)
Normally a JOptionPane creates a modal window.
You need a modeless window which does not block other windows.
https://docs.oracle.com/javase/tutorial/uiswing/misc/modality.html
(b)
You can start different threads to work for your different windows. They can have windows which are shown whenever the responsible thread commands them to. This is a bit difficult and can lead to memory-troubles.
(c)
You can write your own message-panels (e.g. notificaton) which are shown when and how long you like.
Bigger projects use different of these ways to achieve their goals.
A JOptionPane is a component, just like a JPanel. As a component it can be added to any other panel.
The JOptionPane API provides static methods to create a show the JOptionPane on a modal JDialog by default. You can't change this behaviour.
However, you can manually add the JOptionPane to a non-modal JDialog that you create. This is extra work as you now need to handle the closing of the dialog and processing the clicked button.
If you really want to do this then read the JOptionPane API. There is a section on Direct Use which demonstrates the basic code needed to add the JOptionPane to a JDialog.
I have a thread which enables and disables a button in certain random time, if the button clicked when it is enabled an action performed will be executed which will change the image of the button. I am concerned about the synchronization here. Suppose the button is about to get disable and got clicked, so now both threads will execute one to disable it and other to change the image. How should I synchronize this?
All Java GUI toolkits (be it Swing, Apache Pivot, JavaFX, AWT, SWT, Android...) are single-threaded. This means that all listeners will always fire in the same thread. So:
no, you don't need to perform any kind of synchronization,
yes, you need to take care so that disabling and enabling the button happens in the gui thread (wahetever it's called). The exact code is toolkit-specific.
I have a simple program that utilizes Java Swing Timer to display an image for 400 miliseconds, in this period of time I just want to stop all ActionListeners or stop taking ActionEvents. I've got 40+ buttons and want a simple way to do this.
Is there anyway to do that in Java?
Can you determine that you are in this "image displayed" state? The image goes up and you set the state to "image displayed" or whatever. Go through your widgets and decide which ones are supposed to be dead while the image is up. Turn them into Observers of this state value. When the state changes, they either enable or disable, as appropriate. The image code doesn't do anything directly to any widget. It just declares that the state is now "image displayed". It's up to the Observers to decide what to do, if anything, with that information.
Or use the GlassPane. That works too. Of course, the GlassPane shuts down everything. If you need to be more selective, you need a more fine-tuned approach.
You can use a temporary GlassPane instance to consume all events by registering empty listeners to it.
Use an undecorated modal JDialog to display the image. Before you make the dialog visible you would start a Timer. When the Timer fires in 400 ms you close the dialog.
I've had similar issues and typically found that its a design issue that got me in that situation. Being the case, I still had to find away around it. To fix the issue, I kept a list of the elements that I wanted to disable (stop listening) and iterated through them at the beginning and end of the timer. For buttons it should be as simple as:
for(Component c : listOfToggledComponents){
c.setEnabled(shouldItBeEnabled);
}
For buttons, this will grey out the button. Similar things happen to other swing components.
I am trying to develop an application which responds to multiple digital pens (IRIS Pens) so that if any of the pen writes on paper; I relay the output to a single screen. Thus making a multi-input whiteboard for myself.
In Ubuntu these pens are recognized as mouse and thus can be handled in a similar manner as mouse events are handled.
So now what I plan to do is to handle these events in C/C++ using XLib and pass these events to a Java Swing application using JNI callback. I am able to do this but when the X11 window looses focus no events are transferred to the Swing frame. I also tried to use the root window in X11 but it does not seem to work.
Any help would be really appreciated. Thanking you in advance.
How about maximizing the C/X11 window in front of the Java one, and making it transparent? You should be able to see the Java window while still focusing on the C/X11 one.
Since you are using Ubuntu, you can achieve this using the "Opacity, brightness and saturation" plugin for Compiz. It is in the compiz-plugins-main package, and you can activate it with Compiz Settings Manager (from the compizconfig-settings-manager package). When you activate the plugin, alt+wheel is bound by default to change the transparency of the focused window.
Try reading the mouse directly. I don't remember the exact location, but you should find it in something like '/dev/input/mouseX', where X is the number of your device, ranging from 0 to n-1 devices..
When you read the packet, your application should block until the mouse moves and then your read function will return a raw mouse packet which describes the delta (which is probably more useful then the screen coordinates, in your case) and the mouse button statuses.
The raw packet can be decoded as described here: http://www.computer-engineering.org/ps2mouse/
Create a modal dialog and set it to XmDIALOG_SYSTEM_MODAL (the actual name of the property depends on your toolkit: Motif, Gtk, Qt, ...). Dialogs like this block the whole display and can never loose focus.
The drawback is of course that you can't do anything else while this dialog is on the screen.
This entry in the X11 FAQ might help.
I'm trying to internationalise a Java applet and with that, support scripts which are written from right to left. I want to set up component orientations for all java components added to the view automatically.
My solution so far has to listen to all AWTEvent's using the windows mask:
c.getToolkit().addAWTEventListener(listener, AWTEvent.WINDOW_EVENT_MASK);
...and then setting the c/o on each window added, as well as adding component listeners to set c/o on any components added to the window at a later point.
My issue is that JInternalFrames are not handled by this solution, I want to be able to add another listener for these events, much like I have done for windows. Any ideas?
Or alternatively, are there any better approaches to handling script direction for all components in an applet?
Add a ContainerListener to the JDesktopPane. As a component is added to the desktop you can change its orientation.
Do you have a handle on all those JInternalFrames? If so, try the internal frame listener.
http://java.sun.com/javase/6/docs/api/javax/swing/event/InternalFrameListener.html
It notes that it's the analogue to the AWT WindowListener.
AWTEventListener on the current Toolkit will only give you events coming from the toolkit. Generally events generated by lightweight components will have been caused by mouse or key events.
Asking for all of something in a process is usually a very bad sign. A low-level piece of code is making policy for the whole program. A much better approach is to add listeners near to where you create the component, before it is "realised". This is repeated code, but then you probably already have repeated code. So factor out into a method. Then you have only one place to update, unless you have any cases where it doesn't apply which would have broken the global approach.