Bug 47010 Make refactorings more responsive to cancel [refactoring]
I20031119 Most of our current refactorings only do a sporadic check of IProgressMonitor.isCanceled() resulting in a bad canceling behavior. We should make a path over our existing refactoring and queck the cancel state at least after each compilation unit we have processes in checkInput and createChange. The code pattern to add should look like this: pm.worked(...) if (pm.isCanceled()) { // clean-up state if necessary throw new OperationCancelException(); }
org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/core/refactoring/Refactoring.java
*  the refactoring is considered as not being executable.
	 * 
	 * @throws CoreException if an exception occurred during condition checking.
	 *  If this happens then the condition checking is interpreted as failed
	 * 
	 * @throws OperationCanceledException if the condition checking got cancelled
	 * 
	 * @see #checkInitialConditions(IProgressMonitor)
	 * @see #checkFinalConditions(IProgressMonitor)
	 */
	public RefactoringStatus checkAllConditions(IProgressMonitor pm) throws CoreException, OperationCanceledException {
		pm.beginTask("", 11); 
		RefactoringStatus result= new RefactoringStatus();
		result.merge(checkInitialConditions(new SubProgressMonitor(pm, 1)));
		if (!result.hasFatalError())
			result.merge(checkFinalConditions(new SubProgressMonitor(pm, 10)));	
		pm.done();
		return result;
	}
	
	/**
	 * Checks some initial conditions based on the element to be refactored. The 
	 * method is typically called by the UI to perform an initial checks after an 
	 * action has been executed.
	 * <p>
	 * The refactoring is considered as not being executable if the returned status
	 * has the severity of <code>RefactoringStatus#FATAL</code>.
	 * </p>
	 * <p>
	 * This method can be called more than once.