 |
Workspace 6.21.5
|
|
Workspace 6.21.5
|
Event for communicating progress of an operation. More...
#include <Workspace/DataExecution/Events/progressevent.h>
Public Member Functions | |
| ProgressEvent (int progress) | |
| int | getProgress () const |
 Public Member Functions inherited from ObservableEventType< ProgressEvent > | |
| CSIRO_WORKSPACE_API const EventIDSingleton< CSIRO::DataExecution::AllObservableEvents > & | eventID () |
| CSIRO_WORKSPACE_API const EventIDSingleton< CSIRO::DataExecution::ProgressEvent > & | eventID () |
| const EventIDSingleton< ProgressEvent > & | getEventID () const override |
| Public Member Functions inherited from ObservableEvent | |
| virtual | ~ObservableEvent ()=default |
| virtual const EventID & | getEventID () const =0 |
Additional Inherited Members | |
| Static Public Member Functions inherited from ObservableEventType< ProgressEvent > | |
| static const EventIDSingleton< ProgressEvent > & | eventID () |
| Protected Member Functions inherited from ObservableEventType< ProgressEvent > | |
| ObservableEventType ()=default | |
A common task for many long-running operations is to report their progress to interested clients. Because it will often not be known in advance who those interested clients are, an ObservableEvent is ideally suited to this purpose.
This is a good example of how to create an observable event. It derives from ObservableEventType, providing its own name as the template parameter. This is the CRTP (Curiously Recurring Template Pattern) and is a well known and used technique in C++ and elsewhere. You don't need to understand much about how this works, you just need to ensure that you provide your class name as the template parameter.
Because we derive from ObservableEventType, we have its eventID() static function available. This static function allows clients to obtain the event ID without needing to instantiate an object. The only remaining requirement we have to fulfill in using ObservableEvenType is to use the DEFINE_WORKSPACE_EVENT_INSTANCE to create the EventID singleton instance. We do this in an implementation file and it is a simple one-liner:
Because of how the C++ rules for when a static object is created work, it is recommended that you use this macro in the same implementation file as the one that defines your WorkspacePlugin::setup() function. This will ensure that your EventID singleton exists the first time an event of that type is raised and avoids any possible race conditions between threads which might try to use the event for the first time simultaneously. You don't need to understand the details, just put the macro in the recommended place and your code will be safe as far as the C++ rules are concerned. The workspace will never use your event class before setup() is called.
Another feature of this class is that it shows how state information can be included with an event. The progress is supplied as an integer which should be in the range from 0 to 100 inclusive. This integer can be interpretted as an indicator of percentage complete. An event subclass can contain whatever state information is needed to properly describe the event. It would be wise, however, to ensure that the subclass has a properly implemented copy constructor in case clients wish to make a copy of the event. This would be unusual, but allowable.
|
inline |
| progress | The progress associated with the event. It should be a value between 0 and 100, although values less than zero can be used to indicate that no progress information is available. |
|
inline |