> 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
> '============
> 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.