public interface IOperationApprover2 extends IOperationApprover
IOperationApproverto approve the execution of a particular operation within an operation history. Operations that are candidates for execution have already been validated against their current state and according to the rules of the history. Prior to 3.2, an operation approver was only consulted for undo and redo of an operation, not its initial execution.
By the time an IOperationApprover2 is consulted, the execution has already
been requested and it has been determined that the operation is valid.
Approvers should return an
IStatus object with severity
OK if the operation should proceed, and any other severity if
it should not. When an operation is not approved, it is expected that the
object not allowing the operation has already consulted the user if necessary
or otherwise provided any necessary information to the user about the fact
that the operation is not approved.
IOperationApprover, implementers of this extension must be
prepared to receive the approval messages from a background thread. Any UI
access occurring inside the implementation must be properly synchronized
using the techniques specified by the client's widget library.
|Modifier and Type||Method and Description|
Return a status indicating whether the specified operation should be executed.
IStatus proceedExecuting(IUndoableOperation operation, IOperationHistory history, IAdaptable info)
IStatus.OKwill not be approved. Implementers should not assume that the execution will be performed when the status is
OK, since other operation approvers may veto the execution.
operation- the operation to be executed
history- the history performing the execution of the operation
info- the IAdaptable (or
null) provided by the caller in order to supply UI information for prompting the user if necessary. When this parameter is not
null, it should minimally contain an adapter for the org.eclipse.swt.widgets.Shell.class. Even if UI information is provided, the implementation of this method must be prepared for being called from a background thread. Any UI access must be properly synchronized using the techniques specified by the client's widget library.
OK, and the caller requesting the execution will be returned the status that caused the rejection. Any other status severities will not be interpreted by the history.
Copyright (c) 2000, 2015 Eclipse Contributors and others. All rights reserved.Guidelines for using Eclipse APIs.