A simple helper class to wrap the creation of a callback object.
Applications need to derive from this class and must re-implement the function mvIMPACT::acquire::ComponentCallback::execute.
By deriving from this class it will become possible to receive a notification whenever an object derived from mvIMPACT::acquire::Component has changed. So e.g. an application could register a callback on the mvIMPACT::acquire::Device::state property to get notified when e.g. a certain device has been unplugged or restarted.
- Note
- A
change is not necessarily a changed value of a property but also any other change in behaviour like a change in visibility or availability. So when a callback has been registered for a certain read-only component that becomes writable for some reason the registered callback would be executed as well.
A single instance of an object derived from this class can hold an arbitrary number of components which are monitored. components can be registered by calling the mvIMPACT::acquire::ComponentCallback::registerComponent function, so it is not necessary to create and hold a callback instance for every feature that shall be monitored. Since when the callback is executed the information about the object that has triggered it will be supplied as one the input parameters it is easy to decide what has to be done.
- Attention
- Reading and understanding the documentation supplied with the mvIMPACT::acquire::ComponentCallback::execute function is vital to write error-free code!
-
It is NOT save to call mvIMPACT::acquire::ComponentCallback::registerComponent and mvIMPACT::acquire::ComponentCallback::unregisterComponent from parallel threads! If this is absolutely necessary appropriate synchronization code must be wrapped around these calls by the calling code!
- Since
- 1.12.18
- Examples
- Callback.cpp, and GenICamCallbackOnEvent.cpp.
| virtual void execute |
( |
Component & | , |
|
|
void * | ) |
|
inlinevirtual |
The callback function.
Re-implement this function in a derived class in order to implement a custom behaviour.
- Note
- Please note that this function will be executed within the thread context that is causing this callback, thus by any thread belonging to the internal device driver instance. There is a high chance that this is a different thread than any known to by the application, thus appropriate mechanisms to ensure correct execution must be implemented by an application(e.g. GUI applications might send an event to the main thread instead of directly accessing GUI elements from here).
As each device driver instance internally creates multiple threads and since components can be modified by the driver framework from any of these threads, the thread context might in fact be different each time this function gets called. Accessing data from objects that are inherited from mvIMPACT::acquire::Component is thread safe so e.g. property values can be read out in parallel securely! However this 'execute' in a worst case (when several components have been registered to a single callback) might in fact be called in parallel so everything that happens in here should be designed accordingly!
- Attention
- It is NOT recommended to do time consuming stuff here! This function should be considered as something like an interrupt instead: Just take a note about what did just happen and leave. The calling thread will block until this function does return which might have all sorts of consequences if this takes a lot of time. In the worst case e.g. image data might get lost!
GenICam event specific: When dealing with GenICam device events from a single device only within this callback due to the internal design it is guaranteed that this callback will NOT be executed in parallel since the device events will be received sequentially and will always be reported by the same (device driver instance related) thread! So when e.g. registering for changes to the following properties:
