openDAQ
Open data acquisition platform
CoreEventArgsPtr Class Reference

Arguments object that defines a Core event type, and provides a set of parameters specific to a given event type. More...

Inherits EventArgsPtr< Interface >.

Detailed Description

Arguments object that defines a Core event type, and provides a set of parameters specific to a given event type.

Core events are triggered whenever a change in the openDAQ core structure happens. This includes changes to property values, addition/removal of child components, connecting signals to input ports and others. The event type can be identified via the event ID available within the CoreEventArgs object. Each event type has a set of predetermined parameters available in the parameters field of the arguments. These can be used by any openDAQ server, or other listener to react to changes within the core structure.

Notably, core events trigger only on components that are reachable from the root of the openDAQ tree. Actions such as adding properties during the creation of a function block will not trigger the event - only attaching the function block to the tree will. Subsequent modification of the function block's properties, however, will trigger events, as the function block is then reachable from the root.

The Core Event object can be obtained from the Context object created by the Instance that is available to any component within the openDAQ tree structure.

Core event types

This section provides a list of core event types, when they are triggered, as well as their parameter content.

Property value changed

Event triggered whenever a value of a component's property is changed. It triggers after the PropertyObject's and Property's onValueWriteEvent, providing the value of the property after said events are finished processing.

The Property value changed core event does not trigger when updating a component via update, and when beginUpdate has been called.

The "owner" parameter is used to determine whether the change was triggered from within a nested object-type property of the sender component.

The parameters dictionary contains:

  • The Property object owner of the property under the key "Owner"
  • The name of the property as a string under the key "Name"
  • The new value of the property under the key "Value"
  • The relative path to the property owner from the sender component under the key "Path".

The "Path" parameter is used for object-type properties where it represents the path to the property through child Property objects. Eg. the path to the "MyInt" property of child object-type property named "Child1" on a component would be "Child1". In the case of deeper nesting of object-type properties (if "Child1" had another object-type property named "Child2") the path would be as follows: "Child1.Child2.MyInt".

The ID of the event is 0, and the event name is "PropertyValueChanged".

Property object update end

Event triggered whenever a property object finishes updating - at the end of the update call, or when endUpdate is called.

The "owner" parameter is used to determine whether the update end event was triggered from within a nested object-type property of the sender component.

The parameters dictionary contains:

  • The Property object owner of the property under the key "Owner"
  • The dictionary of updated properties under the key "UpdatedProperties". The dictionary has the string names of properties as key, and base object values as values.
  • The relative path to the property owner from the sender component under the key "Path".

The "Path" parameter is used for object-type properties where it represents the path to the property through child Property objects. Eg. the path to the "MyInt" property of child object-type property named "Child1" on a component would be "Child1". In the case of deeper nesting of object-type properties (if "Child1" had another object-type property named "Child2") the path would be as follows: "Child1.Child2.MyInt".

The ID of the event is 10, and the event name is "PropertyObjectUpdateEnd".

Property added/removed

The Property added and Property removed events are triggered whenever a property is added/removed from a component.

The "owner" parameter is used to determine whether the addition/removal was triggered from within a nested object-type property of the sender component.

The "added" event contains the following parameters:

  • The Property object owner of the property under the key "Owner"
  • The added property as a Property object under the key "Property"
  • The relative path to the property owner from the sender component under the key "Path".

The "removed" event contains the following parameters:

  • The Property object owner of the property under the key "Owner"
  • The name of the property as a string under the key "Name"
  • The relative path to the property owner from the sender component under the key "Path". The "Path" parameter is used for object-type properties where it represents the path to the property through child Property objects. Eg. the path to the "MyInt" property of child object-type property named "Child1" on a component would be "Child1". In the case of deeper nesting of object-type properties (if "Child1" had another object-type property named "Child2") the path would be as follows: "Child1.Child2.MyInt".

The ID of the Property added event is 20, and the event name is "PropertyAdded". The ID of the Property removed event is 30, and the event name is "PropertyRemoved".

Component added/removed

The Component added/removed events are triggered whenever a new component is attached or detached from the openDAQ component tree. The event is only triggered when the added/removed component can be reached from the root of the tree. Eg. when creating a new function block, no event will be triggered except for when the entire function block subtree is attached to the main tree.

The sender of the event is always the parent component of the added/removed child.

The "added" event contains the following parameters:

  • The added component under the key "Component"

The "removed" event contains the following parameters:

  • The local ID of the property as a string under the key "Id" The ID of the Property added event is 40, and the event name is "ComponentAdded". The ID of the Property removed event is 50, and the event name is "ComponentRemoved".

Signal connected/disconnected

Triggered whenever a signal is connected to- or disconnected from an input port.

The sender of the event is the input port.

The "connected" event contains the following parameters:

  • The connected signal under the key "Signal"

The "disconnected" event has no parameters. The ID of the connected event is 60, and the event name is "SignalConnected". The ID of the disconnected event is 70, and the event name is "SignalDisconnected".

Data descriptor changed

Triggered whenever the data descriptor of a signal changes.

The sender of the event is the signal.

The event contains the following parameters:

  • The new data descriptor under the key "DataDescriptor"

The ID of the connected event is 80, and the event name is "DataDescriptorChanged".

Component updated end

Event triggered whenever a component finishes updating - at the end of the update call.

The event has no arguments. When called, the component should be checked for changes.

The ID of the event is 90, and the event name is "ComponentUpdateEnd".

Attribute changed

Event triggered when an internal attribute of a component has been changed. Eg. when the "Active" state of the component is modified.

The event has no preset parameters, but instead contains dictionary key-value pairs where the key corresponds to the name of the modified attribute, and the value to its new value.

The Attribute changed event payload always has a "AttributeName" key entry in the dictionary, containing the name of the changed attribute.

The payload then contains another entry using the "AttributeName" value as the key. That entry contains the new value of the attribute.

Currently the following attribute names can be present in the Attribute changed event payload:

  • Signal: "DomainSignal", "RelatedSignals", "Public"
  • Component: "Active", "Name", "Description", "Visible"

The ID of the event is 100, and the event name is "AttributeChanged".

Tags changed

Triggered when a tag of the sender component was added or removed.

The event contains the following parameters:

  • The list of tags (list of string) under the key "Tags"

The ID of the connected event is 110, and the event name is "TagsChanged".

Component status changed

Triggered whenever the status of a component changes.

The sender of the event is the component.

The event contains the following parameters:

  • The new status value encapsulated within an Enumeration object as a value and the status name as a key

The ID of the event is 120, and the event name is "StatusChanged".

Type added/removed

Triggered whenever a new "Type" is added to- or removed from the Type manager. Eg. when a new Struct or Enumeration type is created and added.

The sender of the above event types is always an empty Component pointer.

The "TypeAdded" event contains the following parameters:

  • The newly added type under the key "Type"

The ID of the event is 130, and the event name is "TypeAdded".

The "TypeRemoved" event contains the following parameters:

  • The name of the removed type under the key "TypeName"

The ID of the event is 140, and the event name is "TypeRemoved".

Device domain changed

Triggered whenever the "Domain" of a device changes.

The sender of the above event types is the device of which domain changed.

The "DeviceDomainChanged" event contains the following parameters:

  • The device domain under the key "DeviceDomain"

The ID of the event is 150, and the event name is "DeviceDomainChanged".

Muting core events

Components, as previously mentioned, do not trigger core events until they are connected to the root of the openDAQ tree. This is achieved through internal methods that enable/disable the triggers recursively. By default, each component will not trigger any events - the triggers must be manually enabled. The SDK does this whenever a component is added as a child of a parent, if the parent's core triggers are enabled. When done so, the triggers are enabled recursively for the entirety of the subtree. A converse function can be used to instead recursively mute the events.

Public Member Functions

daq::DictPtr< daq::IString, daq::IBaseObject > getParameters () const
 Gets the parameters of the core event. More...
 

Member Function Documentation

◆ getParameters()

daq::DictPtr<daq::IString, daq::IBaseObject> getParameters ( ) const
inline

Gets the parameters of the core event.

Returns
The parameters of the core event.