I see.

If the code is not going on rely on the check, but is using it for informational purposes, then there is a value to it. In this sense I agree with you. However the OPC Classic part in QuickOPC does not expose the functionality, and you will need to do it the way you suggested.

Best regards

Thank for more info.

I think that you are looking at the issue from somehow improper perspective. Even without subscriptions, with just reads or writes, you do not need to check for anything upfront. You simply call the operation you want to perform, and it succeeds or fails, and your code logic then behaves depending on that result.

In fact, you *have* to it this way anyway. Think it through. There is absolutely no guarantee that if you "check" the connection at one moment, that a moment later it will still work and the operation you call will succeed. It is physically impossible to give such a guarantee. So, if we made it easy for users to check whether the connection is available or not, we will invite them to write code that is either incorrect (if they check it first but then are not quite ready to handle the failure during the actual operation), OR is inefficient (because, to make such code correct, you will end up effectively checking the connection twice, with the first being redundant, as I have just explained).

Regards

Hello.

The QuickOPC subscription model is such that all information that relates to an item is delivered to you through a single channel - that is, the ItemChanged event. There are many kinds of failures that can occur - and some affect just a single item, some affect a group of them (for example, all items that have the same update rate/precent deadband, and form an OPC group, may be affected), and some affect all items that "live" on the same OPC connection (this is the case you have described).

Can you explain what it is that your program is doing with the received data, and why you think you need just a "single" failure handler?

The callbacks and events are just two different ways of delivering the same data (although the callback can be set differently on each item subscription). In other words, there is no difference in having one handler for the ItemChanged event, or having the same callback handler on each item subscription. In both cases, when there is connection-wide failure, the handler will be called with each affected item, and with Succeeded=false.

We have a facility in OPC UA (EasyUAClient object) which gives a single event or callback for connection status changes, but a corresponding feature is not present for OPC Classic.

To your questions:

1. I am not 100% sure if I fully understood your approach, but in general what you wrote makes sense and will probably work. However, as I tried to explain, I do not actually see a reason for combining the events and callbacks, because they deliver the same information.

2. For each notification, the event fires first, then the callback. However this is not currently documented and should be considered an implementation detail on which your code should not rely (although we have absolutely no plans to change it). The events and callbacks on a single EasyDAClient are all serialized, i.e. the next one will not fire until the processing of the previous done is done (has returned). This part *is* guaranteed.

3. Not really - the range of errors is broad and it very difficult, close to impossible, to enumerate them (we could do it for errors they we detect ourselves, but there are errors from the underlying subsystems such as DCOM/RPC infrastructure over which we have no control, and the error Ids then combine their type with their numerical code, and while some codes are known and occur commonly, it is not a closed set of codes).

Best regards