Dear Sir,
I do not have C++ sample code for this at hand, but below I have copied some rules about it, taken from the Concepts documents (which is included with the product, and is also available on the Web).
In general, the SubscribeXXXX method does not generate any errors except for programming bugs (such as null arguments). Even situations like inaccessible server or wrong tag (OPC item) names are all reported through the event handler. Therefore you are all fine with the SubscribeXXXX, and you just need to think about the code inside the event handler.
In the event handler, you first need to check for the Exception property of the EventArgs. If it is not-null, it contains the error information objects. If the Exception is null, then the Vtq property contains a non-null DAVtq object that contains the data (value/timestamp/quality) received from the server. The timestamp and quality are always present. The value itself may be present (non-null) or not present (null), depending on the quality. In general, when the quality is Good (bits 6 and 7 are set), the value is present. You can use the HasValue property of DAVtq for precise test.
Always test the Exception property before accessing the actual result (Value, Vtq, or AttributeData property)
Whenever QuickOPC return an OperationResult object, or an object derived from it, such as ValueResult, DAVtqResult or UAAttributeDataResult, the actual result properties are only valid when the result represents a success, i.e. its Extension property is a null reference. You should therefore always test the Extension property for null-ness first. Only the properties available in the base OperationResult class are always accessible.
The same applies to the Exception property in event notifications, for all event arguments that are derived from the OperationEventArgs class. For example, the Exception property must be checked in event handlers for the EasyDAClient.ItemChanged event (in EasyDAItemChangedEventArgs), and in event handlers for the EasyUAClient.MonitoredItemChanged event (in EasyUAMonitoredItemChangedEventArgs).
If you attempt to get other properties while Exception is not null, the outcome is undefined; most likely an exception will be thrown, but that would be a serious exception indicating a programming error. For more information, see ERROR HANDLING.
Always test the HasValue property before accessing DAVtq.Value or UAAttributeData.Value
The controlling member in the DAVtq class (OPC Data Access Value/Timestamp/Quality) is the Quality property. When the quality is not sufficient, the Value property is not available (and QuickOPC assures that is a null reference in this case). Getting the Value property when it is not available makes little sense.
The same applies to the UAAttributeData class (in OPC Unified Architecture) with regard to its StatusCode and Value properties.
It is commonly said that the value is available whenever the quality (or status code) is not Bad, but precisely speaking, this is not true, as there are some border cases (per OPC specifications) in which this rule does not apply. Your best choice is to test the HasValue property, which has the precise, OPC-compliant functionality built in. Only if HasValue is true, the Value property contains valid data.
For more information, see DATA OBJECTS
The data objects hold the actual data made available by the OPC technology.
Quality and VALUE, TIMESTAMP AND QUALITY (VTQ).
Best regards
Zbynek Zahradnik
