Community
Participate
Working Groups
Build Identifier: 20110916-0149 The code of PreferenceDialog.cancelPressed() is the following: protected void cancelPressed() { // Inform all pages that we are cancelling Iterator nodes = preferenceManager.getElements(PreferenceManager.PRE_ORDER).iterator(); while (nodes.hasNext()) { final IPreferenceNode node = (IPreferenceNode) nodes.next(); if (getPage(node) != null) { SafeRunnable.run(new SafeRunnable() { public void run() { if (!getPage(node).performCancel()) { return; } } }); } } // Give subclasses the choice to save the state of the preference pages if needed handleSave(); setReturnCode(CANCEL); close(); } Notice that if getPage(node).performCancel() nothing will happen, and it will continue with handleSave(), setReturnCode(CANCEL) and close() the dialog. My question is: If the page returns false in performCancel(), should the dialog not close? because it closes anyway. Reproducible: Always
I wanted to say Notice that if getPage(node).performCancel() RETURNS FALSE nothing will happen, and it will continue with handleSave(), setReturnCode(CANCEL) and close() the dialog.
Moving to platform UI. This may be intentional.
This code definitely looks wrong and should be fixed. The safety net was originally inserted to fix bug 29107.
Do you think we should restore the original intent (which was likely a return from 'cancelPressed') ? This code has been there since 2005. True, do you know of any situation where this is causing an actual issue or did the code's oddness just pique your interest ?
(In reply to comment #4) > Do you think we should restore the original intent (which was likely a return > from 'cancelPressed') ? Yes, the code needs to be fixed because the current implementation goes against the API. The user cannot abort the cancel operation by returning 'false'. /** * Notifies that the container of this preference page has been canceled. * * @return <code>false</code> to abort the container's cancel * procedure and <code>true</code> to allow the cancel to happen */
(In reply to comment #4) > True, do you know of any situation where this is causing an actual issue or did > the code's oddness just pique your interest ? I was actually doing a Dialog similar to PreferenceDialog, and I noticed that it didn't work like the javadoc specifies.
(In reply to comment #5) > > Yes, the code needs to be fixed because the current implementation goes against > the API. The user cannot abort the cancel operation by returning 'false'. > > /** > * Notifies that the container of this preference page has been canceled. > * > * @return <code>false</code> to abort the container's cancel > * procedure and <code>true</code> to allow the cancel to happen > */ ok, I'll buy that.
Fixed in 3.8: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R3_development&id=37277ea92b4ea06cf34895b557ce0e068534383c and 4.2: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=123372490d4450f58da92b3ddb084a9000e1908d Thank you for taking time to figure out the problem!