The following tables list the members exposed by AlarmEventServer.
Public Constructors
| Name | Description | |
|---|---|---|
 | AlarmEventServer Constructor | Typical constructor. |
Public Fields
Top
Public Methods
| Name | Description | |
|---|---|---|
 | AckCondition | The client uses the AckCondition method to acknowledge one or more conditions in the Event Server. The client receives event notifications from conditions via the IOPCEventSink::OnEvent callback. This AckCondition method specifically acknowledges the condition becoming active or transitioning into a different sub-condition (and no other state transition of the condition). One or more conditions belong to a specific event source – the source of the event notification. For each condition-related event notification, the corresponding Source, Condition Name, Active Time and Cookie is received by the client as part of the OnEvent callback parameters. The client is required to pass the ActiveTime and Cookie received in the OnEvent callback to the AckCondition method without modification. |
 | Create | Create an event server instance. |
| CreateEventAreaBrowser | Create an Event Area Browser instance. |
| CreateEventSubscription | Add an Event Subscription object to an Event Server. Create an OPCEventSubcription object on behalf of this client and return an interface to the Client. This object will support at least IUnknown, IOPCEventSubscriptionMgt and IConnectionPointContainer. The client can manage the state of this interface including the filter and can create subscriptions to it via ConnectionPoints as described later. |
| DisableConditionByArea | Places the specified process areas into the disabled state. Therefore, the server will now cease generating condition-related events for these conditions. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are disabled for all clients, and they will stop receiving the associated condition-related events. Because of the global effect of this method, some event server implementers may choose not to implement it. In this case, the server should return E_NOTIMPL. A condition may be associated with multiple sources (see Section 2.4). These sources may be distributed among multiple areas. Disabling the conditions in one area does not change the enabled/disabled state of conditions of the same name, which are associated with sources in other areas. For example, the “LevelAlarm” condition may be enabled for sources in “Area1” and disabled for sources in “Area2”. A source is disabled if its condition state is set to disabled or any area within the hierarchy of its containing areas is disabled. |
| DisableConditionByArea2 | Places the specified process areas into the disabled state. Therefore, the server will now cease generating condition-related events for these conditions. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are disabled for all clients, and they will stop receiving the associated condition-related events. A condition may be associated with multiple sources (see Section 2.4). These sources may be distributed among multiple areas. Disabling the conditions in one area does not change the enabled/disabled state of conditions of the same name, which are associated with sources in other areas. For example, the “LevelAlarm” condition may be enabled for sources in “Area1” and disabled for sources in “Area2”. A source is disabled if its condition state is set to disabled or any area within the hierarchy of its containing areas is disabled. If the HRESULT is a FAILED code then the server should return null (Nothing) for the OUT parameter errors. |
| DisableConditionBySource | Places all conditions for the specified event sources into the disabled state. Therefore, the server will no longer generate condition-related events for these conditions. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are disabled for all clients, and they will stop receiving the associated condition-related events. Because of the global effect of this method, some event server implementers may choose not to implement it. In this case, the server should return E_NOTIMPL. A condition may be associated with multiple sources (see Section 2.4). Disabling conditions associated with one source does not change the enabled/disabled state of conditions of the same name, which are associated with other sources. For example, the “LevelAlarm” condition may be enabled for “A100” and disabled for “FIC101”. A source is disabled if its condition state is set to disabled or any area within the hierarchy of its containing areas is disabled. |
| DisableConditionBySource2 | Places all conditions for the specified event sources into the disabled state. Therefore, the server will no longer generate condition-related events for these sources. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are disabled for all clients, and they will stop receiving the associated condition-related events. A condition may be associated with multiple sources (see Section 2.4). Disabling conditions associated with one source does not change the enabled/disabled state of conditions of the same name, which are associated with other sources. For example, the 'LevelAlarm' condition may be enabled for 'A100' and disabled for 'FIC101'. A source is disabled if its condition state is set to disabled or any area within the hierarchy of its containing areas is disabled. If the HRESULT is a FAILED code then the server should return null (Nothing) for the OUT parameter errors. |
| EnableConditionByArea | Places the specified process areas into the enabled state. Therefore, the server will now generate condition-related events for these conditions as long as the source itself is enabled and no containing area in its hierarchy is disabled. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are enabled for all clients, and they will begin receiving the associated condition-related events. Because of the global effect of this method, some event server implementers may choose not to implement it. In this case, the server should return E_NOTIMPL. A condition may be associated with multiple sources (see Section 2.4). These sources may be distributed among multiple areas. Enabling the conditions in one area does not change the enabled/disabled state of conditions of the same name, which are associated with sources in other areas. For example, the “LevelAlarm” condition may be enabled for sources in “Area1” and disabled for sources in “Area2”. A source is enabled if its condition state is set to enabled and all areas within the hierarchy of its containing areas are enabled |
| EnableConditionByArea2 | Places all conditions for the specified event sources into the enabled state. Therefore, the server will now generate condition-related events for these sources. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are enabled for all clients, and they will begin receiving the associated condition-related events. A condition may be associated with multiple sources (see Section 2.4). Enabling conditions associated with one source does not change the enabled/disabled state of conditions of the same name, which are associated with other sources. For example, the “LevelAlarm” condition may be enabled for “A100” and disabled for “FIC101”. A source is enabled if its condition state is set to enabled and all areas within the hierarchy of its containing areas are enabled. If the HRESULT is S_OK, then Errors can be ignored (all results in it are guaranteed to be S_OK). If the HRESULT is a FAILED code then the server should return a null (Nothing) for the OUT parameter, errors. |
| EnableConditionBySource | Places all conditions for the specified event sources into the enabled state. Therefore, the server will now generate condition-related events for these conditions. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are enabled for all clients, and they will begin receiving the associated condition-related events. Because of the global effect of this method, some event server implementers may choose not to implement it. In this case, the server should return E_NOTIMPL. A condition may be associated with multiple sources (see Section 2.4). Enabling conditions associated with one source does not change the enabled/disabled state of conditions of the same name, which are associated with other sources. For example, the “LevelAlarm” condition may be enabled for “A100” and disabled for “FIC101”. A source is enabled if its condition state is set to enabled and all areas within the hierarchy of its containing areas are enabled |
| EnableConditionBySource2 | Places all conditions for the specified event sources into the disabled state. Therefore, the server will no longer generate condition-related events for these sources. The effect of this method is global within the scope of the event server. Therefore, if the server is supporting multiple clients, the conditions are disabled for all clients, and they will stop receiving the associated condition-related events. A condition may be associated with multiple sources (see Section 2.4). Disabling conditions associated with one source does not change the enabled/disabled state of conditions of the same name, which are associated with other sources. For example, the “LevelAlarm” condition may be enabled for “A100” and disabled for “FIC101”. A source is disabled if its condition state is set to disabled or any area within the hierarchy of its containing areas is disabled. If the HRESULT is S_OK, then errors can be ignored (all results in it are guaranteed to be S_OK). If the HRESULT is a FAILED code then the server should return null (Nothing) for the OUT parameter, errors. |
| GetAllServerInstances | |
| GetAttributeValues | |
| GetConditionState | Returns the current state information for the condition instance corresponding to the szSource and szConditionName. The OPCCONDITIONSTATE structure is defined below. See section 2.4 for a discussion of conditions and their states. Some servers may not maintain sufficient condition state information to fully implement this method. In this case, the server should return E_NOTIMPL. If a server chooses to implement this method, it must return valid information for every member of OPCCONDITIONSTATE. |
| GetEnableStateByArea | Returns the current enable state and the effective enable state for each area specified in areas. If the HRESULT is S_OK, then the client can ignore errors (all results in it are guaranteed to be S_OK). If the HRESULT is a FAILED code then the server should return null (Nothing) for each of the OUT parameters. |
| GetEnableStateBySource | Returns the current enable state and the effective enable state for each source specified in sources. |
| onAckCondition | |
| onCreateEventAreaBrowser | |
| onCreateEventCondition | CreateEventCondition default handler that maybe overloaded by NSPluginAEbase. |
| onCreateEventSubscription | |
| onDisableConditionByArea | |
| onDisableConditionByArea2 | |
| onDisableConditionBySource | |
| onDisableConditionBySource2 | |
| onEnableConditionByArea | |
| onEnableConditionByArea2 | |
| onEnableConditionBySource | |
| onEnableConditionBySource2 | |
| onGetEnableStateByArea | |
| onGetEnableStateBySource | |
| onQueryConditionNames | |
| onQueryEventAttributes | |
| onQueryEventCategories | |
| onQuerySourceConditions | |
| onQuerySubConditionNames | |
| onRemoveSubscription | |
| QueryAvailableFilters | This method gives clients a means of finding out exactly which filter criteria are supported by a given event server. This method would typically be invoked before configuring the filter on an OPCEventSubscription object. |
| QueryConditionNames | The QueryConditionNames method gives clients a means of finding out the specific condition names which the event server supports for the specified event category. This method would typically be invoked prior to specifying an event filter. Condition names are server specific. The number of condition names returned will vary depending on the sophistication of the server, but is expected to be less than 30 for most servers, making this interface more appropriate than a custom enumerator. It is expected that the results of the Query will be fairly 'stable' in most situations. However, the Server is in fact allowed to change the available selection at any time. Therefore, a Client should do (or at least allow as an option) a fresh Query every time a selection is to be presented to the end user. |
| QueryEventAttributes | Using the EventCategories returned by the QueryEventCategories method, client application can invoke the QueryEventAttributes method to get information about the vendor-specific attributes the server can provide as part of an event notification for an event within the specified event category. Simple servers may not support any vendor-specific attributes for some or even all EventCategories. Attributes of event notifications are described in the OPC specification Section 2.5.2. Some possible vendor-specific attributes are included in the OPC specification Appendix C. All events of a particular event category have the potential of supporting the same attribute information. For event categories, where different instances of that category in the same server have different attributes, the server should return the union of all attributes and the client must allow for some attributes in event notifications to be null. It is expected that the list of Attributes available for a particular Category on the Server will be fairly 'stable' and that in general, they will not change 'online'. However it should be noted that the behavior of this and the related methods; SelectReturnedAttributes and the ONEVENTSTRUCT of OnEvent do allow for some level of dynamic attribute sets. Specifically, the server can allow online additions to and deletions from the list of attributes which are available for a Category, however it may NOT allow online changes to the Description or data type associated with a particular ID. It is therefore required that Clients be at least prepared to deal with null (Nothing) in the attribute list of ONEVENTSTRUCT. Also, in order to allow for the possibility of a configuration change in the server, a Client should do (or at least allow as an option) a fresh Query every time a list of available attributes is to be presented to the end user for a Category. |
| QueryEventCategories | The QueryEventCategories method gives clients a means of finding out the specific categories of events supported by a given server. This method would typically be invoked prior to specifying an event filter. Servers will be able to define their own custom event categories, but a list of recommended categories is provided in the OPC specification, Appendix B. The number of event categories returned will vary depending on the sophistication of the server, but is expected to be less than 30 for most servers, making this interface more appropriate than a custom enumerator. It is expected that the results of the Query will be fairly 'stable' in most situations. However, the Server is in fact allowed to change the available selection at any time. Therefore, a Client should do (or at least allow as an option) a fresh Query every time a selection is to be presented to the end user. |
| QuerySourceConditions | The QuerySourceConditions method gives clients a means of finding out the specific condition names associated with the specified source (e.g. FIC101).. Condition names are server specific. The number of condition names returned will vary depending on the sophistication of the server, but is expected to be less than 10 for most servers, making this interface more appropriate than a custom enumerator. It is expected that the available condition names for a particular Source on the Server will be fairly 'stable' and that they will generally not change 'online'. However, the Server is in fact allowed to change the available selection at any time. Therefore, a Client should do (or at least allow as an option) a fresh Query every time a selection is to be presented to the end user. |
| QuerySubConditionNames | The QuerySubConditionNames method gives clients a means of finding out the specific sub-condition names which are associated with the specified condition name. Condition names are server specific. The number of sub-condition names returned will vary depending on the sophistication of the server, but is expected to be less than 10 for most servers, making this interface more appropriate than a custom enumerator. It is expected that the available subcondition names for a particular condition on the Server will be fairly 'stable' and that they will generally not change 'online'. However, the Server is in fact allowed to change the available selection at any time. Therefore, a Client should do (or at least allow as an option) a fresh Query every time a selection is to be presented to the end user. |
| Remove | The server object is disposed. Do the required cleanup. |
| TranslateToItemIDs | Many OPC Alarm/Event servers are associated with OPC Data Access servers. Since these servers may provide a Data Access interface to some or all of the attributes associated with events, applications need the ability to determine the specific ItemID for one or more specific attribute ID codes given an associated source ID in order to be able to access the attribute via the Data Access interface. TranslateToItemIDs performs the required translation. This function will be useful for the case where the client wishes to use the OPC Data Access interface to subscribe to real-time data associated with a given event or alarm. Given an event source, and an array of associated attribute ID codes, return an array of the item ID strings corresponding to each attribute ID. The event source, along with the associated attribute IDs are returned as part of the OnEvent callback mechanism. Attribute ID codes and descriptions for a given event category can also be queried via the QueryEventAttributes method. The server must return null (Nothing) for those attribute IDs that do not have a corresponding item ID. |