I'm working on a program that traverses a list of objects every pass through. When an object's "time" (i.e. number of passes) is up, it brings up a JDialog to request its next task. The problem is how to deal with multiple objects making this request on a single pass.
If I make the JDialog modal, each object makes its request in turn, which is what I want; but the main program window is unavailable, which I do not want.
If the JDialog is not modal, multiple instances appear, one for each pass, which I do not want; or, if I set it up as a singleton, only one instance appears but only the last object int the list to make the request gets to use it.
Is there a way I can pop up the dialog, leave other windows available to the user, and have the other objects wait their turn to use the dialog?
As noted in comments, the problem can be addressed by altering the modality of the parent Window. On the downside, the "behavior is implementation-dependent."
As an alternative, consider traversing the objects in the background thread of a SwingWorker and adding new candidates to a suitable component, e.g. JList, JTable, or JTabbedPane. Selecting an element form the component would bring up a conventional modal dialog, removing the element on completion. A related example is shown here. Each of the suggested components can be labeled with an icon representing its status.
Solved this by setting the original window's ModalExclusionType to "application" and toggling back to "no exclude" once finished.
Related
I was recommended to use InteractionDialog rather than Dialog, but I'm failing to see the advantages. What I can see is a problem. What I need is letting the user enter a PIN or whatever and wait for their answer. This is needed both on the EDT thread (the user choose to save the PIN) and on other threads (a web page requires the PIN for login).
With Dialog,
I can call it from the EDT thread and it works nice.
When on a different thread, I can be trivially adapted by a one-liner in the callee (see getFromGui in my linked question).
With InteractionDialog,
I can use it easily from other threads via some simple wait/notifyAll magic.
I can't use it from the EDT thread, except via callbacks like okBtn.addActionListener(...), which is verbose and ugly.
So I am confused and asking:
What do I gain from the InteractionDialog?
Is there a simple way how to use it uniformly no matter what thread I am on?
There are two separate things here:
Modality
How it works
A dialog can be modal or non-modal but it isn't interactive like an InteractionDialog. The modal dialog blocks the EDT internally using InvokeAndBlock so the current thread stops until there's a response from the dialog. This is convenient but has some edge case issues. E.g. the event that launched the dialog might trigger other events that would happen after the dialog was dismissed and cause odd behavior.
But that's not the big thing in modality. Modality effectively means the form behind you "doesn't exist". Everything that matters is the content of the dialog and until that is finished we don't care about the form behind. This core idea meant that a dialog effectively derives form and as such it behaves exactly like showing another form effectively disabling the current form. What you see behind the dialog is a drawing of the previous form, not the actual form.
Text fields can pose a problem. Because the way the dialog is positioned (effectively padded into place within its form using margin) the UI can't be scrolled as text field requires when the virtual keyboard rises. Since people use dialogs in such scenarios we try to workaround most of these problems but sometimes it's very hard e.g. if the dialog has a lot of top margin, the virtual keyboard is open and covering it. Or if the user rotates the screen at which point the margin positioning the dialog becomes invalid.
Note that in InteractionDialog Some of these issues such as the margin to position also apply.
Now InteractionDialog is a completely different beast that sprung out of a completely different use case. What if we want a dialog such as a "color palette that floats on top of the ui?
We can move it from one place to another but still interact with the underlying form. That's the core use case for InteractionDialog. As such modality is no longer something we need so it was never baked into InteractionDialog although it technically could have been (but it doesn't make sense to the core use case).
It's implemented as a Container placed into the layered pane of the current form so the form around it is real. Because the form is "live" layout works better and the removal of modality makes some edge cases related to editing slightly better. There are still some inherent problems with dialog positioning and rotation though. It also allows you to click outside of the dialog while input is ongoing which might be a desirable/undesirable effect for your use case.
Overall I try to use dialogs only for very simple cases and avoid input when possible. If I use input I never use more than one field (e.g. no-username and password fields) so I won't need to scroll. These things work badly for native UIs as well e.g. with the virtual keyboard obscuring the submit button etc. Since those behaviors are very hard to get right for all resolution/virtual keyboard scenarios.
Based on the answer from Shai, I wrote a form working as the base class for most of my dialogs. Basically, it shows the content from the subclass and adds the "OK" and "Cancel" buttons.
There's a method for use from the EDT thread like
public void showAndThen(BooleanConsumer consumer) {
assert CN.isEdt();
...
okBtn.addActionListener(a -> {
lastForm.show();
consumer.accept(true);
});
cancelBtn.addActionListener(a -> {
lastForm.showBack();
consumer.accept(false);
});
}
where BooleanConsumer is a trivial void accept(boolean b) interface.
There's another method for use from other threads
#Override public final boolean ask() {
assert !CN.isEdt();
final BooleanTransfer transfer = new BooleanTransfer();
CN.callSerially(() -> showAndThen(result -> transfer.set(result)));
return transfer.await();
}
where BooleanTransfer is a two-method class where the thread calling set passes a boolean to the thread calling await.
Im trying to make a java program that will popup/notify me to stop what I am currently doing and do something. more like a reminder. My question is how will I make a pop up in java.
I found this docs, but dont know how to implement for the parent component.
JOptionPane.showMessageDialog(??,"this is a modal dialog.");
The answer depends, do you have a parent component (like a JFrame or other component) or are you simply display the JOptionPane independently?
If you are simply displaying the JOptionPane independently, you can simply pass it null.
If you are displaying the JOptionPane as part of a large application, with windows and other components, you can simply pass it a reference of what ever component you want the JOptionPane to displayed relative to, such as the window or most accessible container/component
The parent argument (if supplied) simply allows the dialog to act as a modal (blocking) dialog for the window which contains the supplied component. This requires the user to have to dismiss the dialog before they can continue to interact with the parent window/component
Take a closer look at How to Make Dialogs for more details
I have created a swing application in Netbeans environment. This application consists of four frames. Now my requirement is, after filling A frame when user clicks "Next" button then A's data should be buffered somewhere and then go to second form and so on. Finally when user lands in the last form, at this point i want the total data of all forms should be stored in database.
I am not sure how to achieve this. Can anyone suggest some useful resource or idea?
Consider having one non-GUI model class, that can be passed into the view (GUI) classes, either via a constructor parameter, or a setter parameter, i.e., public void setModel(Model model). Then all views can have the same Model instance passed into them.
When the first window has its data "submitted", it submits it into the one shared model. If you're using a Model-View-Control structure, then this is usually done by the Control, but if your program is simple, a Model-View is probably all you need. The other windows can be notified by the Model of the changed data, and then change their displays accordingly.
But as an aside, also please ask yourself, how many professional applications do you use that jump from window to window? Not many because it is a very distracting and often unpleasant experience for the user. Most use a single main application window that swaps gui views within this window and with an occasional dialog window popping up when information is needed in a modal fashion. Please have a look at The Use of Multiple JFrames, Good/Bad Practice?
This method is supposed to merge two the definitions of two entries for a single in a glossary. It creates an instance of the GlossaryEntryMergeUI class (extension of JFrame), which walks the user through the merging process. The user clicks a button to submit and the window closes. The merge method extracts the merged definitions and returns the combined glossary entry.
What is the best way to make the merge method wait for response from the MergeUI? I tried using InvokeAndWait, but I couldn't figure out how to make it work.
public GlossaryEntry merge(GlossaryEntry otherEntry){
//First, merge the definitions
GlossaryEntryMergeUI thisMerge = new GlossaryEntryMergeUI(this,otherEntry,mergeSignal);
thisMerge.setVisible(true);
thisMerge.setAlwaysOnTop(true);
GlossaryEntry combined = new GlossaryEntry(word);
combined.addDefinitions(thisMerge.getDefinitions());
return combined;
}
consider to look for CardLayout instead of switch between two or more Windows
if is there Serializable or Observate, then better is wrap the code into invokeAndWait(), for simple switch between two Windows is there invokeLater()
I'd suggest not using two JFrames in same time, one JFrame and another Window would be JDialod or JWindow, because (for example if is there BackGroung Task) sometimes is so hard swith Focus from one JFrame to another, not to move JFrame toFront() ...
This has nothing to do with use of invokeAndWait or invokeLater and all to do with listening on one thread for a response in another. If you're not using a modal dialog for this, such as a JOptionPane (which is quite easy to use and can hold a very comnplex GUI if needed), consider using a listener or otherwise known as the observer design pattern to notify the non-GUI component when the GUI has been acted upon.
Also, is GlossaryEntryMergeUI the only GUI the user comes in contact with? Or is it called into being from another GUI, perhaps a "parent" GUI? If the latter, then a modal dialog, not a JFrame is the way to go. Edit: or a CardLayout as per mKorbel's excellent answer.
In my program I have two JFrame instances. When I click next button I want to show next frame and hide current frame. So I use this.setVisible(false) and new Next().setVisible(true). But in Next window if I click back button I want to set previous frame to be visible again and next frame must be ended (which means it must be exited).
Is there any special method(s) to do this? How can I do it?
Consider using CardLayout instead of hunting for how many JFrames there are. Then..
only one JFrame would be needed
any of Next/Back Actions will be only switching between cards
There are lots of examples in this forum - e.g. as shown here.
That is an odd & quirky GUI. I suggest instead to run a JFrame for the main GUI, and when the user wants to search, pop a JOptionPane (or modal JDialog) to accept the details to search for. This will not have the effect described above, but will follow the 'path of least surprise' for the end user.
If you want to destroy a JFrame releasing all associated resources you shold call dispose() method on it.
You may place your JFrames on a list data structure and keep a reference to current position according to the window you are displaying. In that way it will be easy to move to next and previous. But note that each frame added to the list will use memory and will have its state as you placed it in to the list.
If you are trying to create a wizard like UI, you should look up Sun(oracle)tutorial here.
create the instance of your main window in next() window.. and use same method which you chosed befoe to hide your main window, for example if your main window is named as gui then what we have to do is.
gui obj = new gui();
and if you click on back button now than do these also
this.setVisibility(false);
obj.setVisibility(true);
that's all you need.
good luck.