Interesting. A bit of Googling gives some interesting results, e.g.:

embarcadero.newsgroups.archived.at/public.delphi.oleautomation/201008/1008111153.html
stackoverflow.com/questions/2449411/delphi-6-oleserver-pas-invoke-memory-leak
www.delphigroups.info/2/41/73231.html
forum.delphi.cz/index.php/topic,14291.0.html

I have only quickly glanced over them; the StackOverflow answer seem to be quite interesting and relevant to our case. From what I can tell, it's a Delphi issue. We do not control any of the Delphi-side code that has to do with accessing COM objects, and it is some Delphi object that is being leaked.

If we are given arguments indicating that the problem is in the QuickOPC component itself, OR - even if it's not - a hint of how the component side can somehow provide a workaround for it, we will have another look at it. Otherwise, it's up to the consuming side to somehow deal with it...

Best regards

It is quite possible that our example code for Delphi is buggy in this respect - i.e. that it does not free the objects as it should. We may fix that in the future, but it should be mad clear that the main intent of the examples is to show how to invoke various functions in the product - and not to provide a "full" application code. And, we are no Delphi experts here, Delphi is just one of the tools that can be used with QuickOPC.

Isn't it so that the console application (our examples) simply does not detect/display the memory leaks the way the VCL applications does? That would explain why, even with leaks present, our (console-based) Delphi examples do not report it.

And, in the case of you VCL application, do *you* actually dispose of all the objects - or did you just copy over our code?

Regards