Are all instances of a control sharing the same PropertyBag ?

[IanS]

I've created an ocx using VB6 and it works just fine when deployed and used in other applications - as long as there's just one of them on the form.

If I have more than one of my ocx's on the form then any design time changes in one of them also get applied to the other ocx ?

Are they sharing the same property bag ?

Surely they're supposed to work independently of each other ?

Thanks
Ian

[brucevde]

Each instance of an OCX control has a separate "property bag". Changing the design time properties of one control should not affect the other.

Post your code.

[LaVolpe]

Also, how are you changing the properties? Via property sheet or custom property page?
If property page, show us your PropertyPage_ApplyChanges event.

[IanS]

Solved this one - thanks.

Just out of interest though...

I noticed the problem while running an application in the IDE. Changed a property (in code) in one instance of the control and when I read the property from another instance of the control I noticed it had also changed.

I have the properties in Public Property Let and Property Get procedures. The actual property values are stored in the ocx in variables.

The problem was that the variables were declared 'Global' in a Module in the ocx project. When I moved them to the ctl and made them private the problem went away.

Still strange though - I didn't think global variables in one instance of the compiled ocx would affect the same variables/properties in other instances of the ocx?

[LaVolpe]

FYI: The bas modules in a usecontrol are shared among all instances of the usercontrol. So any public properties/variables in those modules are also shared.

[IanS]

FYI: The bas modules in a usecontrol are shared among all instances of the usercontrol. So any public properties/variables in those modules are also shared.

Thanks - could be quite handy as a way to communicate between instances. Even something so simple as a shared counter allowing each instance to know how may other instances there are.

Also quite scary too - having to make sure that there's nothing in the module that could cause a problem if some other instance changed a variable.

Thanks
Ian

[LaVolpe]

Thanks - could be quite handy as a way to communicate between instances. Even something so simple as a shared counter allowing each instance to know how may other instances there are.

EXACTLY!!!! I use it for that purpose. Let's say I want a class that is public to all usercontrols, I can create the Public class in the module. Let's say that when one uc is "active" the others need to know about it, well the active one can set a reference to itself in a Public variable and unref itself when it becomes inactive. There are so many more possibilities too.

And here is where I use a counter for an example. In some of my controls, I use GDI+. GDI+ must be initiated and freed. Let's say 10+ of my ocx's added to some coder's form. Well I don't want every control to start a new instance of GDI+, so the controls call the module to increment a count when they load. When the count = 1, GDI+ is started. When each control terminates, the controls also call a function to decrement the count. When the count = 0, GDI+ is terminated. And yet another example using same counter idea: If I'm doing a lot of custom drawing, I am using memory DCs and bitmaps. Do I want multiple ocx's caching their own copies of these? Probably not if I can avoid it as it is a waste of memory and GDI heap, so I can share the DC and bitmap(s) among the ocxs, destroying them when counter = 0.

There is a caution here. When controls are uncompiled and you END your project via an END statement, VB toolbar's STOP button, or END button in the Error/Debug messagebox, the Terminate events of the controls do not fire. When the uc is compiled into an actual ocx, then things are different. If some user adds your ocx to their project and terminates their project with END, your uc still fires its terminate events.