Apache OpenOffice (AOO) Bugzilla – Issue 83596
RFE: Java parent window for modal dialogs
Last modified: 2013-02-07 22:36:39 UTC
There's no possibility to obtain java.awt.Dialog (or Frame) from running instance of the OpenOffice.org. It would be nice to have some function which can return java.awt.Dialog ( Frame ) of any OpenOffice.org window. I know that we can use VCL and create / use native dialogs. But it's a pain. It's quite complicated to create dialogs with something like JTable, etc. Please, can you review this RFE and tell us if this is possible and if this will can be implemented?
TM->requirements: please have a look.
Is there any progress on this issue? More and more extensions are using java to create dialogs (e.g. some very popular extensions including OpenOffice.org2GoogleDocs, LanguageTool, clker.com openoffice addon, mOOo Impress Controller, eVoice, R4Calc, OpenCards). All these extensions suffer from this bug, because without a parent a java-dialog is almost unusable. Beside the fix of this issue, it would be very helpful to know whether and for which release this problem is planned to be fixed. This would at least allow extension developers allow to adapt their efforts.
I don't think that the java dialog is almost unusable without a parent. You can switch to JFrame, ie. not modal window. I was forced to use not modal windows because of this issue and I like it, I like it probably more than modal windows now ;-) If you want to be sure that your document window will not be closed until your not modal window is visible, you can implement XCloseListener, throw CloseVetoException and you have to intercept .uno:CloseDoc & .uno:CloseWin commands too.
I agree that 'almost unusable' exaggerates a little ;-). However, any user which opens a java-extension-dialog, switches to another application for second (e.g. to check mails or to do whatever) will be highly confused if this dialog is no longer visible if she returns back to OOo. IMHO users assume any kind of dialog started from within OOo to belong to OOo, and therefore to reappear if OOo is reactivated. Without a clear parent-child relationship between the OOo-frame and java-windows this can not be achieved easily. Maybe one possible workaround would be to listen for OOo-frame de-/activations to make the dialogs to stay on top if OOo becomes activated (and to hide them on deactivation). My current 'solution' is to make JDialog/JFrame to stay always on top. But this is anything but a nice solution.