April 4, 2010 4 Comments
How to implement “Modal Dialog” in JavaFX ? Before going into details of implementation, lets first have a look at common requirement for “Modal Dialog”.. It must block..
- Mouse Events beyond the modal dialog
- Key Events beyond the modal dialog
- Execution of current Thread until dialog is disposed
JavaSE 6 allows to specify various types of modality as in ModalityType. We will try to implement behavior some where between Application and Document Modal
Blocking Mouse Events is very easy, we just need to place a Rectangle whose width and height spans the entire Scene. Then set Node.blocksMouse attribute to true.
Key Events can be restricted if we could ensure that none of nodes other than child of Modal-Dialog receives focus. One way to achieve this is to disable default focus traversal. Get a list of all focus-traversable nodes in the dialog. We can set Node.focusTraversable attribute to false. Now add key-listeners to all nodes. Since focus traversal is disabled, the node will receive TAB key events. When the node receives TAB key event we can explicitly move the request to next node by invoking Node.requestFocus. Request focus for previous node for Shift + TAB key event. Please refer to FocusCycleRoot.fx for more information.
Now comes the interesting part – block execution of current thread – But JavaFX is executed on Event Dispatch Thread – EventQueue.isDispatchThread() will return true. So we cannot block this thread, as it will freeze the user interface. Assuming that the underline Toolkit of JavaFX is built on top of AWT Toolkit, we can use AWT APIs to get around this situation. Before blocking the current thread, we can push a new EventQueue instance into System-Event-Queue, so as to create an alternate path for dispatching events. After disposing the modal dialog, we can restore the original event queue using pop. Please refer to EventQueueUtils.java for more information.
Above solution is not stable enough and also not future proof. It assume that Toolkit is AWT and we have access to EventQueue (For which we need to sign the Applet), also the API may not be compatible with other profiles. In addition to this, pop API has tendency to create deadlock, there were attempts to fix this in various releases, but still doesn’t provide stable behavior (especially when called from JavaFX).
So we may have to revisit the requirement – “block execution of current thread”. Instead we can write the program in such a way that the display of MessageBox will be the last statement in current execution block. Thus we don’t have to block the thread. Then MessageBox can handle redirection to other blocks of code by invoking functions. Thus MessageBox will act like a decision box. This approach will work with most cases and can emulate the “block thread” behavior. Also you don’t have to sign the application. Please refer to MessageBox.fx for more information.
Please try it out and let me know feedback..