Hi Ariel, Carsten,
Thanks a lot for your help! Best regards, Christina On Mon, Aug 24, 2009 at 8:52 AM, Carsten Driesner <[email protected]>wrote: > Ariel Constenla-Haile schrieb: > > Hello Christina, Carsten, >> >> On Friday 21 August 2009, 03:52, Carsten Driesner wrote: >> >> >>> I tried to give up on docking support and I've chosen the solution with >>>>>> UNO >>>>>> dialogs. My dialog with the tree control should be non-modal. If the >>>>>> current >>>>>> document window is the parent of my window , my window is not modal . >>>>>> (the user cannot change the focus window- document). >>>>>> >>>>>> >>>>> There is something I don't understand in your last two sentences. For >>>>> me >>>>> it looks like a conflict. If a window is not in modal mode a user CAN >>>>> change the focus. E.g. the file dialog always starts in modal mode and >>>>> you cannot change focus to the dependent document window. >>>>> >>>>> >>>> Sorry, my bad , I intended to write "modal". >>>> >>>> >>>> >>>>> If I set the parent to be >>>>> >>>>> >>>>> >>>>>> the desktop , the two windows are totally independent. In this case I >>>>>> have >>>>>> to handle manually every event like closing the window, resizing it >>>>>> etc >>>>>> ( when the user closes the document window I need my small dialog to >>>>>> be closed too). Is there any other alternative that allows the two >>>>>> windows to be dependent, but also the focus to be changed? >>>>>> >>>>>> >>>>> How do you start the dialog? Please don't use execute() which starts >>>>> the >>>>> dialog in modal mode. You have to use show() otherwise you could see >>>>> the >>>>> described behavior. >>>>> >>>>> >>>> I start the dialog with execute() method from XDialog interface. The >>>> XDialog interface doesn't seem to offer a show() method. Is there any >>>> other place where I find it? For now , I create a non-modal dialog , >>>> creating a different window which is invisible and setting this window >>>> as >>>> Peer for my dialog. Of course this is a temporary solution because I >>>> would need to handle all the events from the document window. >>>> >>>> >>> Sorry for the late answer but I have tried to look for a solution. >>> Unfortunately I wasn't able to find anything what can help you here. The >>> object you get via the DialogProvider service just implements XDialog >>> and XTopWindow neither implements anything that you need. I fear that >>> your workaround is currently the best available solution. Please write a >>> request for enhancement and the owner to [email protected]. I hope that >>> we can extend the implementation to support your use case. >>> >>> >> >> I think that one of the issues here is that - according to the API >> specification - a top window is not a window ... >> >> Anyway, the css.awt.XDialog is an css.awt.XTopWindow, so it implements >> also css.awt.XWindow. Query for this last interface and invoke >> setVisible(false). You will have to take care of three (or more) things: >> >> * setting the window not visible does not close it; there is no close() >> method for awt windows, you have to dispose them by invoking dispose() >> >> * but you have to dispose them when listening at two things: >> >> ** when the parent window is being closed: if the window you set at its >> parent is closed, you may surely want to also close your window >> >> ** if you set the frame's container window as parent, it may happen that >> the document gets closed but not the container window (for example, when >> this is the last appl. window opened and the user presses the X on the menu >> bar to close the document but not terminate the office; or when the frame is >> reused to load another component in it). >> In case you want your modal-less window to be closed when the document it >> was opened for gets closed, you have to listen for the document closing >> event. >> >> > Hi Ariel, > > Thanks for the clarification. I even looked into the source code but didn't > detect that a top window is a really window, which is a natural thing. I > didn't check this problem on a real life Office which sometimes reveals more > information than a little code review. So it looks like you are very > familiar with the AWT toolkit now. Thanks again for your help. > > Regards, > Carsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
