I am developing a Swing application with custom CSS rendering. As part of the system I use JDialogs as well, but I need to access certain components outside of the dialog (emergency buttons).
For this I chose following method:
all dialogs are non-modal. Those I want to make quasi-modal, will be setAlwaysOnTop.
There is always one quasi modal dialog up. In this case I put another dialog up, below this one, full-screen, semi-permanent.
This "blur" dialog shall cover the whole screen, catch mouse events and forward them to the emergency buttons only. In parallel I opened gaps on it so that the emergency buttons can be seen through the semipermanent surface without any effect.
The blur dialog can never be focused or activated (I have a vetoable listener for this)
Everything works fine, until someting happens and the blur dialog seems to cover my quasi-modal dialog. However, if I move any external application window over it, the quasi-modal dialog remains on the top. Instead of a complicated explanation, see picture un following link: http://lost.lost.hu/javascreen.png
So far I tried to debug repaints, events, everything, and could not find anything that would cause this. Especially the case depicted above challenges me to understand what is going on here.
I have recently updated to Java 1.7, in hope to get rid of this phenomenon, but today it came back.
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 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'm developing a Java 6 applet which allows users to view OO (v.3.2) documents (read only), and if they choose, click a button which launches a new JDialog window, with the document displayed in it which allows the user to and mark and redact it as they wish. Once they are done, they can close the JDialog, which saves the document to a server and redisplay the updated document (read-only again) in the original applet window
I guessed that I could do this with a single instance of an OfficeBean, embedded in a Swing Panel. However, I cannot seem to successfully move my Panel (containing the OfficeBean) from the applet to the JDialog when the "Redact" button is clicked. All I get is a blank area in the JDialog where the document should be. I get no errors.
I have currently managed to get round this by creating new instances of the OfficeBean every time I need to display the document (once when the applet is loaded, again when the user chooses to redact and it is opened in a JDialog, and finally when they click "Save" in the dialog and the redacted result is displayed in the applet again.) However this means three trips to and from the server where the documents originate. That seems mad to me.
I'm in no way a Swing expert and may well be making a silly mistake. However, I've done a lot of fiddling around, debugging and googling and can't seem to get this to work. Can anyone help me in this? Am I trying to do something which is fundamentally impossible? I hope not.
One rule in Swing is that a component can only be displayed / attached to one part of the gui "tree" at a time. When you "move" your component to the dialog, are you first removing it from the applet?
Wow, what a stupid question you might say. But is it possible? I have a mouse move event in a Jpanel and it works even when the application is not in focus, now can I have something like that for the clicking event or something similar. And most importantly I don't want other apps (even something like the main menu) to lose focus when i click on my app.
I thought of the system's event queue but i'm not sure where that would lead me to.
Thanks in advance.
[EDIT - the purpose]
I want to create an app that mimics the users interactions with the system in a later time. for example a user takes the mouse and clicks and writes and my app will mimic that in say 2 hours time. ofcourse i would need a system hook for the outer events but i wanted to avoid os-dependant code so i basically capture the screen, take it to my app,for example the user clicks on an icon in the captured picture and then for making that come to life, i translate the coordinates to the real icon and click it (with a Robot) and in this way i can capture the user's events in my own app. the problem occurs when the user clicks on the main menu or right clicks (he's doing that in my app, and my app does that to the system so my app is in between) and ofcourse the real main menu will lose focus when the user tries to click on one of it's items.
sorry for my english.
I'm still not sure I follow what you are trying to do. But the concept of an app getting focus when you click on it is fundamental to the GUI and I suspect rather difficult to get around.
I just found this:
Focusable Windows
To support palette windows and input methods, client code can prevent a Window from becoming the focused Window. By transitivity, this prevents the Window or any of its descendants from becoming the focus owner. Non-focusable Windows may still own Windows that are focusable. By default, every Frame and Dialog is focusable. Every Window which is not a Frame or Dialog, but whose nearest owning Frame or Dialog is showing on the screen, and which has at least one Component in its focus traversal cycle, is also focusable by default. To make a Window non-focusable, use Window.setFocusableWindowState(false).
In this doucment http://java.sun.com/j2se/1.5.0/docs/api/java/awt/doc-files/FocusSpec.html
That sounds like it might do what you want.
I am working on a project that is using a JTable to display, among other things, a column of dates. We needed validation for the user input for dates, so I have implemented a combination of masking for format validation and parsing for actual date validation. I have done this using a custom CellEditor for the date column.
Inside my MaskedCellEditor, I have a JFormattedTextField. I setup the masking for dates. Then I add an InputVerifier to allow for actual validation. My InputVerifier implements verify() to check: 1. textField.isEditValid() 2. DateValidator.ValidDate(). If either is invalid, verify returns false and the InputVerifier locks the focus into the text field (the cell editor) and a small message dialog is displayed reminding the user of the date format.
The error message is a small, undecorated, non-modal, non-focusable JDialog that pops up underneath the cell being edited. It disappears on a keypress or a successful date verification. It is working great except for a small edge case.
If the user selects a menu button on the top of the application while an invalid edit has popped up the dialog, it switches screens, destroying everything currently on the screen (including the table). However, since the dialog is being shown and a keypress/successful edit has not occurred, the dialog is never hidden. It remains visible in a completely unrelated context on a different screen. Once the user has switched off the screen with the table, there is no way for the user to get rid of the dialog.
I have debated throwing either a Timer and/or a MouseListener on the dialog itself that would cause it to disappear, but I feel that I am ignoring the actual problem. The dialog is never being disposed of and I am pretty sure its because it is still set to be visible and it is preventing the garbage collector from getting rid of it.
I have a Cleanup method on the panel holding the JTable, but I cannot find a good way to reference the dialog (a component of the InputVerifier) in order to get rid of it. The dialog is pretty far removed from the table's parent panel. (Panel -> JTable -> CellEditor -> JFormattedTextField -> InputVerifier -> JDialog)
Any ideas on how to force the dialog to be hidden when the table is destroyed? If you need more details, let me know. I'm trying not to get you guys bogged down in the details, but there is a lot going on.
As a first thought, can you not go down the listener approach. If you have a closeErrorDialog() type method that gets called when upon successful valdiation, then you can also call it when a menu action is selected.
As an alternative, perhaps you could control the transition from menu to menu in some way, and create a "cleanup" method which will close down any exisiting error dialogs. This would allow for any other actions that need to take place when changing menus, to happen in the same place.
Just a couple of quick ideas of the top of my head. Hope they are along the lines of what you meant
Many people will vote me down for saying this, but it sounds like your dialog should be modal so that users can't switch away from it without dismissing it first. Or at least disable the menus that allow people to switch away while this dialog is displayed.