Hello,

I actually worked on this earlier when we discussed it. And, unfortunately, it turned out that I was wrong - it looks like that is not possible to do it with the current QuickOPC version.

The reason for it is minor, but critical: The serialization/deserialization works on "streams". The stream interfaces are properly exposed to COM from .NET, but the actual concrete stream objects have no default constructors and therefore cannot be created from COM.

It would be relatively easy to add COM-exposed .NET objects to QuickOPC that would enable the creation of streams from COM. But it would be an API/feature change that we never do into a released version - only into a new version.

So, if you are interested and can wait, I can put it into the plan and we will expose this functionality in QuickOPC 2018.2 or 2018.3. But currently, it seems impossible.

Regards

I have had a further look at this. It looks like you cannot easily hook events to _EasyUAClient (I could probably put it together as well, but it really won't be as short as it should be). So, when you want to use events, I recommend to go back to TEasyUAClient, and free it explicitly.

Moreover, I now understand what you meant by mentioning TServerEventDispatch. It appears to be a memory leak caused by Delphi, though.

I wrote down what I have found so far, and the recommended approaches - including sample code. It is in the Knowledge Base article here: kb.opclabs.com/Reference_counting_in_Delphi .

Best regards

Thank you, I will have a look at that. But I cannot do it now, and I will be mainly out of office for a day, maybe two.

Can you, in the meantime, try the following?

1. Replace "write: TEasyUAClient;" by "write: _EasyUAClient;", AND
2. Remove "write.Free; write := nil;".

Doesn't that get rid of the memory leak?

Best regards

It looks like that you are doing something differently from what we have in our examples. We do not use TServerEventDispatch (at least not directly), so I cannot comment on that.

Maybe you can send a piece of code that shows what you have in mind and how you are using it.

Best regards

I do not have that much knowledge of Delphi. But I was under assumption that for interfaces, Delphi compiler takes care of the reference counting (and freeing when the count goes to zero), so there is actually no need to free eventArgs explicitly, assuming it is declared as _EasyUADataChangeNotificationEventArgs (an interface, not an object). But I might be wrong.