|
From: Jan H. <jh...@sc...> - 2008-02-12 13:50:27
|
Fixed 1 and 2 by adding disposeDialogContentPane() and moving wizard.addPages() to the WizardDialog.setWizard() method. Point 3 still exists, but is a minor one. If the changed behavior due to moving the addPages method proves to be less suitable than having it on gui-construction (createDialogContentPane) please provide a use-case. Kind Regards, Jan On Mon, 2008-02-11 at 14:43 +0100, Jan Hoskens wrote: > Some more thoughts about 2): > > I would opt to call wizard.addPages() in the setWizard() method of the > WizardDialog. However the wizard.addPages() method states in its javadoc > that it can be used to lazily add pages just before the dialog becomes > visible. This seems a bit strange to me. The visual components are only > created when needed (during dialog construction) so these can be seen as > lazily created. The actual dialogPages (thus the modelling) should be > available when the wizard is set on the dialog, which seems reasonable > to me at this moment. At the moment that you want to have a Dialog, it > seems logical to have all your pages set. > > The new owner wizard of the petclinic sample does break with this change > because it creates the dialog first, then the form to display. Changing > this sequence fixes the wizard. > > Kind Regards, > Jan > > On Mon, 2008-02-11 at 13:41 +0100, Jan Hoskens wrote: > > Hi, > > > > I've run into some issues concerning the dispose of the > > ApplicationDialog. The default CloseAction of ApplicationDialogs is set > > to DISPOSE and will have the effect of disposing the actual JDialog > > which resides in ApplicationDialog. > > > > Issues I encounter are: > > > > 1) subclasses don't 'dispose' the content pane they provide, however the > > surrounding JDialog is disposed. This can be fixed by providing an > > additional method disposeDialogContentPane. Any components kept in > > fields and created in createDialogContentPane can have their reference > > set to null in the disposeDialogContentPane. > > > > 2) subclasses may use the createDialogContentPane for other reasons than > > just the creation of visual components. Eg WizardDialog actually adds > > its pages in that method. This is not a real part of the content > > creation and momentarily has problems because it gets executed every > > time the wizard is opened. It reflects in duplicate pages (see issue > > RCP-536). I don't think we want to remove them in > > disposeDialogContentPane and re-add them again but fix this by calling > > it only once. I'm looking for the best spot/way to do this. > > > > 3) the create/dispose methods may not be transparent. Meaning when using > > the TitledApplicationDialog, a titlepane is used on top. When creating > > the dialog, titlePane.getControl() is used. When closing the > > ApplicationDialog, the JDialog can be disposed as well as any content in > > the TitledApplicationDialog by the disposeDialogContentPane, but the > > titlepane still has its component cached. Is this a problem? > > > > WDYT? > > > > Kind Regards, > > Jan > > > > > > **** DISCLAIMER **** > > http://www.schaubroeck.be/maildisclaimer.htm > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > **** DISCLAIMER **** > http://www.schaubroeck.be/maildisclaimer.htm > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev **** DISCLAIMER **** http://www.schaubroeck.be/maildisclaimer.htm |