No, this isn’t documented. I stayed away from doing so intentionally, and instead just required the developers to modify all such settings just once at the beginning, because the behavior depends heavily on implementation details and is subject to change. I did not want to “commit” to some ability that might get removed later.

So far all customers I communicated with were OK with this – they had no need to change these parameters later, during the lifetime of the app.

(from email)

For clarity, and forgive me if this is in the Docs – for this point:

“The reason for that is that only SOME, but NOT ALL of them behave the way you have described (i.e. the change will affect subsequent operations). For examples, process-wide COM security settings can only be set once in the process lifetime, and further attempts to change them are ignored by Windows.”

Is it documented somewhere which can be changed anytime and which are only once per process lifetime?

In earlier versions, up to 5.32, COM support was a separate component, ran out-of-process from the application (“Local Server”), we had the Options utility, and the global parameters could have been set only using that utility but not from the code. The changes made using the Options utility affected all applications written with QuickOPC, because they were stored in a single place in the registry.

In version 5.33 (kb.opclabs.com/What%E2%80%99s_New_in_QuickOPC_5.33 ) and later, COM API is built on top of the .NET components. It runs in-process with the application. There is no Options utility, but the global parameters can be changed from the code. Such changes always affect ONLY the application that changes them (in fact, only that process run – they are not stored anywhere beside memory of the process, so they need to be set each time it runs).

In .NET, global parameters are usually set using the static (C#)/shared (VB.NET) properties on EasyXXClient objects. There are no such properties in COM, but we have made COM objects that allow the developer to access these global properties nevertheless. They are called EasyXXClientConfiguration. See e.g.
opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...html#Setting%20Parameters.html . So, the COM developer just needs to instantiate e.g. an EasyDAClientConfiguration object, and he can then modify the global parameters.

In general, the developer is advised to set ALL these properties just once, and before calling any OPC operations. The reason for that is that only SOME, but NOT ALL of them behave the way you have described (i.e. the change will affect subsequent operations). For examples, process-wide COM security settings can only be set once in the process lifetime, and further attempts to change them are ignored by Windows.

To wrap it up, I think that the newer versions are better suited to what the customer wants, because each application settings are already isolated from others. The only downside compared to the older version is the absence of storage (such as config file or registry) for the settings, and the GUI utility to manipulate them – which is something I know about and is on the list, but not with high priority.

I hope this answers all your questions.

(from email)

We are working with a user that has some existing COM applications that use version 5.31 [...]. In some use cases, they wanted to disable the automatic subscriptions that are made when reads or writes are performed. Version 5.31 still has the “EasyOPC Options” utility for configuring the different EasyOPC COM settings, and we followed the procedure listed on your forums here to update those settings and it worked fine.

One concern that they brought up is that these global settings (OPC-DA Globals tab) are not able to be changed in the code like they are in .NET. We believe their thoughts are, what if they want different client applications to have different settings for some of those global properties? Say if they want certain client applications to have the automatic subscriptions enabled, while other client apps have this disabled? In .NET, they would theoretically be able to do this by changing those static properties before they create a new instance of the client object – but this wouldn’t work for their COM applications, correct? Am I correct in thinking that if those static properties are changed after an object’s instantiation, they won’t have any effect on that particular instance, just on ones created after that point? Would that be an acceptable practice to you?

I also know that in later versions, you have changed how the COM part of the toolkit is created to basically be a wrapper around the .NET part. Does this have any effect on the accessibility of these global properties programmatically (say in VB6)? Or is that simply a function of how COM objects themselves work, and the global properties must be set as a part of when they are registered or something of that nature?

So basically, part of the customer’s concern is that they see all of the different global settings and are thinking “what happens if we need to change these settings for specific client applications, but leave others the way they are currently?”. Right now they have 3 different applications that run on the same machine – and may be adding more in the future. We are trying to help address those concerns.

I know they will likely be open to upgrading to later versions of the toolkit (and perhaps having a mix of VB6 and .NET applications), so that should be an option they are willing to consider, especially if later versions will give them more control over their concern above.