Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / COM / September 2005



Tip: Looking for answers? Try searching our database.

VB6 sharing variables between instances of a control

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Chip Camden - 08 Sep 2005 20:39 GMT
Ran into something strange and couldn't find anything in the
documentation to confirm this as expected behavior.  I created an
ActiveX control in VB6.  In a program I include two instances of the
control.  The control has Let/Get properties to access a global variable
(I know, I know).  If the global variable is declared in a Standard
Module, both instances of the control appear to share the variable.  If
it is declared within the UserControl module, the variable is not
shared.  Does this make sense?

TIA
Ken Halter - 08 Sep 2005 21:03 GMT
> Ran into something strange and couldn't find anything in the
> documentation to confirm this as expected behavior.  I created an
[quoted text clipped - 6 lines]
>
> TIA

Perfect sense. Variables declared Public in a bas module are available
throughout the current project.... regardless of the project type. There can
be dozens of instances of a control/dll/form/whatever running. They all get
their own set of private variables and they'll all share the same bas
module.... which is why API declarations or subs/functions/whatever,
declared Public in a bas module are available throughout the project.

Signature

Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..

Ken Halter - 08 Sep 2005 21:13 GMT
> declared Public in a bas module are available throughout the project.

I should add... this can come in handy once in a while. For one thing, it
allows you to keep track of the number of instances. If you wanted to limit
the number to exactly 2 (or whatever), you could raise an error in the
Initialize event, which would prevent it from being instantiated. A lot of
other uses too. This was the first that popped into my head.
'============UserControl code
Option Explicit

Private Sub UserControl_Initialize()
  glNumberOfInstances = glNumberOfInstances + 1
  If glNumberOfInstances > 2 Then
     glNumberOfInstances = glNumberOfInstances - 1
     Err.Raise 429 'use a more appropriate error
  End If
  Debug.Print glNumberOfInstances
End Sub

Private Sub UserControl_Terminate()
  glNumberOfInstances = glNumberOfInstances - 1
  Debug.Print glNumberOfInstances
End Sub

Public Property Get NumberOfInstances() As Long
  NumberOfInstances = glNumberOfInstances
End Property
'============Module code
Option Explicit

Public glNumberOfInstances As Long
'============

Signature

Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..

Joseph Geretz - 23 Sep 2005 05:37 GMT
> I should add... this can come in handy once in a while.

Very handy indeed. We have an application which implements a common
navigation widget on every form. Since the navigation context is common
throughout the entire application, changes made via one widget need to
update all other widgets accordingly. We use Global (BAS) variables to
maintain shared state. We also use a system of callbacks (each widget
'registers' itself in a global table of object references). When specific
events occur, all widgets are notified to synch themselves accordingly.

Very hand indeed!

- Joe Geretz -

>> declared Public in a bas module are available throughout the project.
>
[quoted text clipped - 28 lines]
> Public glNumberOfInstances As Long
> '============
MikeD - 08 Sep 2005 23:39 GMT
> Ran into something strange and couldn't find anything in the
> documentation to confirm this as expected behavior.  I created an
[quoted text clipped - 4 lines]
> it is declared within the UserControl module, the variable is not
> shared.  Does this make sense?

Perfect sense. That's exactly how it works.  I'm sure it's documented
*somewhere* but I couldn't tell you where. Basically (no pun intended),
anything Public in a .bas module is global and is even "shared" among
instances because it goes on the global heap for that module (the OCX or
DLL). IOW, anything global is not encapsulated (generally, this leads to
problems, but it can be used to your advantage). This is true for ActiveX
DLLs too.

For example, let's say you have an ActiveX DLL (or OCX) used by 2 or more
programs, which all instantiate an instance of some class (any class
exposed, even if not the same class). If you have a global variable in the
ActiveX project, ALL those programs "share" that global variable (whether
it's actually exposed to the client program or not).

Signature

Mike
Microsoft MVP Visual Basic

Schmidt - 09 Sep 2005 10:24 GMT
> For example, let's say you have an ActiveX DLL (or OCX) used by 2 or more
> programs, which all instantiate an instance of some class (any class
> exposed, even if not the same class). If you have a global variable in the
> ActiveX project, ALL those programs "share" that global variable (whether
> it's actually exposed to the client program or not).
No, that doesn't work across processes.
Even in VB-Threads the Public Members of VBs "*.bas-Modules" are running
inside their own apartment and cannot be shared - the whole thing is working
only over multiple instances in the *same* thread.

Olaf
MikeD - 09 Sep 2005 20:47 GMT
>> For example, let's say you have an ActiveX DLL (or OCX) used by 2 or more
>> programs, which all instantiate an instance of some class (any class
>> exposed, even if not the same class). If you have a global variable in
>> the
>> ActiveX project, ALL those programs "share" that global variable (whether
>> it's actually exposed to the client program or not).

> No, that doesn't work across processes.
> Even in VB-Threads the Public Members of VBs "*.bas-Modules" are running
> inside their own apartment and cannot be shared - the whole thing is
> working
> only over multiple instances in the *same* thread.

You could very well be right. It's so extremely rare that I ever use global
variables at all (let alone in an ActiveX project) that I could be mistaken.

Signature

Mike
Microsoft MVP Visual Basic

Tony Proctor - 10 Sep 2005 13:56 GMT
I can confirm you're mistaken Mike  :-)  VB globals are instanced per COM
apartment, which effectively means that each thread [that accesses the DLL]
in each process gets a separate copy

       Tony Proctor

> >> For example, let's say you have an ActiveX DLL (or OCX) used by 2 or more
> >> programs, which all instantiate an instance of some class (any class
[quoted text clipped - 11 lines]
> You could very well be right. It's so extremely rare that I ever use global
> variables at all (let alone in an ActiveX project) that I could be mistaken.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.