However, there is another definition… Dialogs that block the rest of the UI…
In that regard all dialogs in Codename One are modal; they block the parent form since they are really just forms that show the “parent” in their background as a simple image. A while back we showed you how to
“fake” a dialog
, which is pretty cool. We ended up using this technique a few times until eventually we asked ourselves: “Shouldn’t this be a part of the framework?”.
Well, now it is. We just added InteractionDialog to Codename One which tries to be very similar to Dialog in terms of API but unlike dialog it never blocks anything. Not the calling thread or the UI.
Its really just a container that is positioned within the layered pane. Notice that because of that design you can have only one such dialog at the moment and if you add something else to the layered pane you might run into trouble.
Using the interaction dialog is be pretty trivial and very similar to dialog:
final InteractionDialog dlg = new InteractionDialog(“Hello”);
dlg.setLayout(new BorderLayout());
dlg.addComponent(BorderLayout.CENTER, new Label(“Hello Dialog”));
Button close = new Button(“Close”);
close.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
dlg.dispose();
}
});
dlg.addComponent(BorderLayout.SOUTH, close);
Dimension pre = dlg.getContentPane().getPreferredSize();
dlg.show(0, 0, Display.getInstance().getDisplayWidth() – (pre.getWidth() + pre.getWidth() / 6), 0);
This will show the dialog on the right hand side of the screen, which is pretty useful for a floating in place dialog.
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended…. If that is the case please let us know via the comments section below.
7 Comments
Is my understanding correct: the ‘fake’ dialog is the component with focus, so no events got to the parent form, but because the parent form is ‘live’ under the dialog, the UI of the parent form can be updated from the dialog ? (Unlike in ‘real’ dialogs where the parent form is just a static ‘background’ to to the dialog).
If there is no need to update the parent form is there any particular reason to prefer one over the other ?
Is there something that we need to do apart from refreshing libs. I am not able to add this code snnipet and test it as InteractionDialog is not available.
With current Dialogs the dialog takes over the entire screen so you can’t drag a widget from a dialog to the form beneath it or some other unique use cases.
For 98% of the cases I’d just use dialogs, this is a special case tool.
You will need to use Update Client Libs (not refresh libs which is something else) when this is updated. Since we didn’t update the plugin yet this is only available by building the source right now. The plugin will probably be refreshed sometime next week.
Good! However, is there a way the interaction dialog can listen to events like if outside of the bounds of the dialog is clicked/touched so the dialog can animate or close. Can we determine if the interaction dialog is showing? For example dialog.isShowing(). I see some interesting use cases like in the new google plus app.
Just add a pointer listener to the parent form to see. A dialog is showing method would probably be useful, feel free to file an RFE on that into the issue tracker.
Pointer pressed not solvingthat because the pointer press is also passed through the InteractionDialog to the parent form