R.,
yes, you are right, and the ‘if…then..else’ is an appropriate way. In fact, the “Concepts” document contains this guidance, too:
Pseudo-code for the full Notification event handler may look similar to this:
if notificationEventArgs.Exception is not null then
An error occurred and the subscription is disconnected, handle it (or ignore)
else if notificationEventArgs.RefreshComplete then
A “refresh” is complete; handle it (only needed if you are invoking a refresh explicitly)
else if notificationEventArgs.Event is null then
Subscription has been successfully connected or re-connected, handle it (or ignore)
else
Handle the OPC event, details are in notificationEventArgs.Event. You may use notificationEventArgs.Refresh flag for distinguishing refreshes from original notifications.
We need some notification about the successful connection because, as opposed to OPC Data Access, there may be no OPC-A&E event shipped to the client after a successful connection (with simple event or tracking, or with condition events if Refresh is turned off).
On possible improvement for future versions of the API is to have something like “event kind” in the event arguments, so that a ‘switch’ statement can be used instead of series of ‘if…then…else’ as above.
Best regards,
