From your other post, my understanding was that you want to use subscriptions to make sure the client remains connected to the server. If that is the only reason in your project to use subscriptions, then you do not have any need to actually see and process the events generated by the subscriptions. What would you do with the data in them, anyway?

Just calling SubscribeXXXX will do what you want (and then UnsubscribeXXXX to revert).

Best regards

Good catch!

However, the sentence in the manual refers to a possible "future" that may never happen. It is not in any plans right now.

It had to do with a concept that we had where the event source (the OPC client piece) would be separated by some relatively slow connection (such as network) from where the events are consumed by the QuickOPC API (your program). Basically, QuickOPC split into two parts and doing "remoting". Even if it gets implemented (which is unlikely) at some point, it will only be for specific use cases - and most likely *not* yours.

Feel free to pick whichever method you prefer, but because the code comes out a bit simpler and we do have an example for PullItemChanged, that's what I would do.

Best regards

BTW, if you are not using the subscriptions for anything else, why bother trying to pull the event? Well, maybe because of the memory consumption and eventual event queue overflow; but there won't be many events, and the queue size is limited, so it won't eat all available memory.

Hello.

There is no such example - and there is a reason for it. It is recommended to use PullItemChanged instead, because the resulting code will be simpler, and there is no performance hit.

For PullItemChanged, the examples are here: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...Access%20-%20Event%20pull.html .

Best regards