(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.
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.