Internally, the event for connection changes (on EasyUAClient, that is) is implemented and tested OK. It will be available in the next version, together with other improvements (some quite big, such as support for OPC UA Events and Conditions).

The software is ready to be released, but we are waiting with the release, and I cannot give a specific date currently. There is a peculiar reason for it: For several reasons (which are not relevant at the moment), the new version will require .NET Framework 4.6 or higher (and the developer projects will have to target .NET 4.6 or higher). Taken broadly, this should not be a big problem, because the previous versions requires .NET 4.5 (or 4.5.1, 4.5.2), and .NET 4.6 is an in-place upgrade to that. And, Microsoft is no longer supporting anything between .NET 4.0 and 4.5.2, effective approx. middle of January 2016.

But we know that sometimes our customer have their good reasons to stay with older frameworks, and in some cases even cannot migrate easily. So, while majority of our customers will be OK with .NET 4.6, we do not want to disappoint the remaining few. And the likeliness of it diminishes with the time - the later we release, the smaller number of developers will be affected, as people migrate away from older frameworks anyway, gradually.

So we need to weigh the pros and cons of when to release. In the meantime, we are working on the software anyway and accumulating the improvements in the new version.

There are two parts to my answer:

First, I agree that in some scenarios it is good to know more about the connection status. As stated already, the new event on EasyUAClient will take care of that in version 5.36. In the current "in-works" implementation it provides the Connected/Disconnected status and the reason for disconnection (the Exception), but based on your input, we may enhance it to include more info - this is yet to be decided.

Second, and here I still disagree with you, such information should normally have no influence on the application logic. It should be for display, logging, diagnostics, but not more. Your reasoning seems to be based on several assumptions that do not actually hold.

One of them is that connection-wide problem are somewhat special and need a special attention. In fact, they are not. The final intent of the application is to communicate with a "tag" in the server; the connection is just a means to that purpose. There are many "tag-level" problems that can occur, i.e. there can be problems with a single tag or a group of tags, while other tags behave just normally. Such problems include, but are not limited to, e.g. a server misconfiguration, or a subscription-level (e.g. keep-alive) problem which affects only some monitored items but items that live on other subscriptions (inside the *same* connection) are unaffected. You get an error indication (Exception object) with each result/notification for each monitored item. A well-written application must therefore be prepared to handle situations in which the result/notification for a monitored indicates an error. When such logic is already in place, all failure situations are covered - and there is no need to add extra logic to look for connection-wide failures. The code just needs to handle the failures on the "tag" level - because they *can* always appear - and that, in fact, handles everything already.

Second incorrect assumption is that by somehow detecting a connection problem, and having extra logic to handle it, you make the application more efficient. This is not the case. If you call SubscribeMultipleItems with 1000 items, and the server is not accessible, the call won't take 1000 times longer. Furthermore, let's say that you call SubscribeXXXX with just 1 item, and the server is inaccessible and is put on "retrial period". Then, if you call another SubscribeXXXX immediately after the first call, it will *not* try to connect to the server again. It will simply return the error from the first call, without even trying. Therefore, your argument "meaning if the connection is not healthy there's no point in trying to subscribe more items right away and wait for another timeout" is in fact correct, *but* that logic is already built into the QuickOPC! What you are doing is tremendously complicating your own code for no reason.

In QuickOPC, a subscription denotes a permanent intent to be subscribed to something. As such, it does never fully "fail" - even if it's not possible to make the subscription the first time, the component will keep trying - until the corresponding UnsubscribeXXXX call. Want to make an HMI screen with 100 items? Just subscribe to them ONCE, do not think about reconnections, and display the notifications as they come. Want to make a logger for 1000 items? Do the same - subscribe once, and log the notifications. Forget about those connection handling complications on you side.

If you still think that your application requires to handle the connection status, then please explain why - but not in lower terms of API calls ("I need to make this because I think it is more efficient"), but rather in the term of the application domain - what do you want to do with the data and how. Perhaps that would then explain the "mismatch" between the perceived requirements and behavior of the component.

Best regards

Not in version 5.35.

Version 5.36 will have an EasyUAClient.ServerConditionChanged event for this. The release date for this version is not fixed yet but I'd expect it be in 2-3 months from now.

However in most cases, requests for a feature like his come from misunderstanding of how QuickOPC works. I would welcome if you can explain your use case/what are you trying to achieve.

Best regards

Thank you very much for detailed explanation. It is very useful for us to know how the developers use (or want to use) our software.

Access to connection state appears to be recurring requirement, and I will try to put to higher position in the planning list.

Regarding "b)", some of what you are looking may be already possible to extract from the information currently provided, but in a complicated manner - I now understand that it needs to be "packed" nicely for it to be usable to the developer without much further coding.

Thanks again, and best regards

Unfortunately, the answer is negative - there is no such capability currently. It is on the "wish list", however.

Can you please describe more about the use case that requires this? Is you your goal more to
a) have way to "get" the state at any time you want (instead of receiving it via events), or b) getting MORE information than you are getting now? (and if so, what precisely are you interested in?).

In case you need more details in cases of errors, there are actually properties on the exception(or inner exceptions) that may already have this information. Let me know what are your requirements.

[moving this to a different forum category]