frysk.gui.monitor.observers
Class TaskSignaledObserver
java.lang.Object
frysk.gui.monitor.GuiObject
frysk.gui.monitor.observers.ObserverRoot
frysk.gui.monitor.observers.TaskObserverRoot
frysk.gui.monitor.observers.TaskSignaledObserver
- All Implemented Interfaces:
- SaveableXXX, Observer, TaskObserver, TaskObserver.Signaled
public class TaskSignaledObserver
- extends TaskObserverRoot
- implements TaskObserver.Signaled
Methods inherited from class frysk.gui.monitor.observers.ObserverRoot |
addFailed, getActionPoints, getBaseName, getCurrentAction, getCurrentActionCombos, getCurrentFilterCombos, getFilterPoints, getInfo, load, save, setReturnAction |
taskFilterPoint
public TaskFilterPoint taskFilterPoint
taskActionPoint
public TaskActionPoint taskActionPoint
TaskSignaledObserver
public TaskSignaledObserver()
- TaskSignalObserver. Extends TaskObserverRoot and implements TaskObserver.Signaled
Provides functionality for the Signaled Frysk Core observer in the UI.
apply
public void apply(Task task)
- Specified by:
apply
in class TaskObserverRoot
unapply
public void unapply(Task task)
- Specified by:
unapply
in class TaskObserverRoot
updateSignaled
public Action updateSignaled(Task task,
Signal signal)
- Description copied from interface:
TaskObserver.Signaled
- The SIGNAL is pending delivery to the task. Return
Action.BLOCK to block the task's further execution.
XXX: This gets weird. At present and in theory, a client
wanting to discard a signal would need to sequence the
following: tell the task to scrub discard the signal; tell
the task to remove this observer from the set of blockers;
return Action.BLOCK so that this task is added to the set
of blockers. Perhaps it would be better to always add an
observer to the blocker pool and then require explict
removal.
- Specified by:
updateSignaled
in interface TaskObserver.Signaled