... use buttons on the parent JFrame? I have a number pad on the JFrame that uses Robot to allow you to use only a touchscreen with the program. The JDialog needs to allow the users to use the JFrame's numpad buttons while still letting the JDialog keep the focus. Is there a way to do it?
Thanks.
Its only been a while since you first posted the question.
By contrast its been 2 weeks since you got an answer to this question: http://forum.java.sun.com/thread.jspa?threadID=5140132, yet you still haven't replied indicating whether the suggestion given was helpfull or not.
Its been 11 days since you got an answer to this question: http://forum.java.sun.com/thread.jspa?threadID=5140983
And its been 4 days since you got help on this question: http://forum.java.sun.com/thread.jspa?threadID=5144997
So, I'll get back to you in two weeks, I'm not about to waste any more time on someone who doesn't appreciate help they have received in the past.
You're right camickr, I should have made more sure to put a final word on those last topics and shown my appreciation where it's due. I usually post on conversation forums and I usually forget about threads quickly.
I didn't mean to sound pushy with my last post, I just thought I should bump it since it was probably buried early on (I posted in the early hours).
Sorry again.
I don't know anything about Robot, but by definition a modal dialog prevents the user from interacting with its parent until it has been closed. So if you want to give the user access to the parent, the dialog cannot be modal. You might consider adding whatever buttons you need to the modal dialog, or else make the dialog non-modal and simply deactivate any UI controls that you don't want the user to be able to use while it is open.
Geoff
> The JDialog needs to allow the users to use the JFrame's numpad buttons while still letting the JDialog keep the focus
Try using a non-modal dialog and then for each button use:
button.setFocusable( false )
This will prevent the button from gaining focus. Of course the user could still click elsewhere on the frame and it would gain focus.
The problem I get with not setting it as a modal is that the statement execution in the parent keeps right on going after it opens the dialog, so an if statement that would otherwise be called depending on the users actions never gets called because the code doesn't wait for the dialog to close (like it did when it was a modal dialog) before continuing.
That, and just to clarify, by giving focus to any part of the parent will cause it to cover up the nonmodal dialog? Is there no way to set the whole parent JFrame to not be focusable? (is the dialog also counted as being part of the JFrame though?)
> The problem I get with not setting it as a modal is that the statement execution in the parent keeps right on going after it opens the dialog, so an if statement that would otherwise be called depending on the users actions never gets called because the code doesn't wait for the dialog to close (like it did when it was a modal dialog) before continuing.
Just add a WindowListener to the dialog and handle the windowClosed event, and run the if statement there.
> That, and just to clarify, by giving focus to any part of the parent will cause it to cover up the nonmodal dialog? Is there no way to set the whole parent JFrame to not be focusable? (is the dialog also counted as being part of the JFrame though?)
If you pass the JFrame to the constructor of the JDialog as its owner it will always stay on top of the JFrame.
So I just got through adding an additional Numpad to the dialog, it ended up not looking half bad. Thanks for all the help guys, it was still valuable as a lesson even if I never got it working the way I wanted.
Just to make sure though, when windowClosed is called, it runs through it's statements right before actually closing the window right? That reminds me, I'm using setVisible(false) to close the window, should I not be doing that?
> Just to make sure though, when windowClosed is
> called, it runs through it's statements right before
> actually closing the window right?
Wrong. The WINDOW_CLOSED event is generated after the window has been closed; a WINDOW_CLOSING event is generated before closing the window.
> That reminds me,
> I'm using setVisible(false) to close the window,
> should I not be doing that?
That is the only way I know of...
> Just to make sure though, when windowClosed is called, it runs through it's statements right before actually closing the window right? That reminds me, I'm using setVisible(false) to close the window, should I not be doing that?
setVisible(false) will not generate windowClosed event, and will not release the resources allocated for the dialog.
If you want to close the dialog call dialog.dispose(), and set the default close operation to DISPOSE_ON_CLOSE.
If I were to change my code to dispose instead of set it to not be visible then I would need to change the way it executes the finishing code (because it depends on a boolean in the dialog). I'd prefer to leave it the way it is. The only concern I have is, with using setVisible, the garbage collector will eventually dispose of the dialog, right? And dispose() just does it right away?