dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: use of global multiuse

  1. #1
    Randy Baron Guest

    use of global multiuse


    I am designing an app that will consist of a "shell" main form that will hold
    ocx's for each of it's screens. Each ocx will have a corresponding dll holding
    all the business logic. All data access will be routed through a dll that
    will (among other things) hold the ado connection to the database (an access
    mdb).

    I originally had a scheme where I was passing the object reference of the
    data dll to each of the other dll's. However, if I make the data dll global
    multiuse, my understanding is that vb will create a global object and that
    anything running in the process, like all my other dll's, will have access
    to that instance of the object without having to set any explicit references.
    The documentation is unclear on this so I tried it and it seems to work -
    only one connection is made and all the dll's that reference the data dll
    use the same connection. Has anyone else used a global multiuse object in
    this way? Is there any downside to this scheme (assuming all objects remain
    in-process)?

    Randy

  2. #2
    Mark Alexander Bertenshaw Guest

    Re: use of global multiuse

    Randy -

    I believe it is slightly more complicated than that. A new "global"
    instance of the class will be created for each client component that
    accesses it. For instance, if we have Project A, Project B, and Project C.
    Project C has a class, Class1, which is the global multiuse class. Project
    A has Class 2 and Class 3, each of which access the same instance of
    Project1.Class1. However, Project B.Class 4 and Project B.Class 5 access a
    different instance of Project1.Class 1.

    HTH

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK
    "Randy Baron" <rbaron@shrinenet.org> wrote in message
    news:392d1d03$1@news.devx.com...
    >
    > I am designing an app that will consist of a "shell" main form that will

    hold
    > ocx's for each of it's screens. Each ocx will have a corresponding dll

    holding
    > all the business logic. All data access will be routed through a dll that
    > will (among other things) hold the ado connection to the database (an

    access
    > mdb).
    >
    > I originally had a scheme where I was passing the object reference of the
    > data dll to each of the other dll's. However, if I make the data dll

    global
    > multiuse, my understanding is that vb will create a global object and that
    > anything running in the process, like all my other dll's, will have access
    > to that instance of the object without having to set any explicit

    references.
    > The documentation is unclear on this so I tried it and it seems to work -
    > only one connection is made and all the dll's that reference the data dll
    > use the same connection. Has anyone else used a global multiuse object in
    > this way? Is there any downside to this scheme (assuming all objects

    remain
    > in-process)?
    >
    > Randy




  3. #3
    Randy Baron Guest

    Re: use of global multiuse


    Mark,

    That's what I thought too, which is why I made my post. Each of the DLL's
    in my app is a seperate project. However, they are accessing the same connection
    object contained in the data DLL.

    What I do is this. I have a login screen which calls a login DLL. The login
    DLL instantiates a specific reference to the data DLL to access the security
    database (these are all .mdb files). If the user is authorized I destroy
    that instance of the data DLL and call the dcOpenConnection function of the
    data DLL to instantiate the global instance of the data DLL and connect to
    the data .mdb file. After that my other DLL's (each in seperate projects)
    access the global object, but the dcOpenConnection function is not called
    from any of these DLL's. Yet they successfully query the database.

    I have debug.print statements in the intialize and terminate events of the
    data DLL and they each fire twice - once for the specific instantiation in
    the login DLL and one for the global instance. As I understand it, each instance
    shares functions but gets its own copy of data. Now, the connection is considered
    data (stored in a variable) so each instance would get its own copy. Therefore,
    if each seperate DLL project was getting its own instance, wouldn't I need
    to open and store a connection in each instance? Or do I have it completely
    wrong?

    BTW, do you know how to get the address of the global instance? Objptr will
    work on a specifically instantiated object, but not on the global one.

    Randy



    "Mark Alexander Bertenshaw" <Mark.Bertenshaw@virgin.net> wrote:
    >Randy -
    >
    >I believe it is slightly more complicated than that. A new "global"
    >instance of the class will be created for each client component that
    >accesses it. For instance, if we have Project A, Project B, and Project

    C.
    >Project C has a class, Class1, which is the global multiuse class. Project
    >A has Class 2 and Class 3, each of which access the same instance of
    >Project1.Class1. However, Project B.Class 4 and Project B.Class 5 access

    a
    >different instance of Project1.Class 1.
    >
    >HTH
    >
    >--
    >
    >---------------------------------------
    >Mark Alexander Bertenshaw
    >Programmer/Analyst
    >Prime Response
    >Brentford
    >UK
    >"Randy Baron" <rbaron@shrinenet.org> wrote in message
    >news:392d1d03$1@news.devx.com...
    >>
    >> I am designing an app that will consist of a "shell" main form that will

    >hold
    >> ocx's for each of it's screens. Each ocx will have a corresponding dll

    >holding
    >> all the business logic. All data access will be routed through a dll that
    >> will (among other things) hold the ado connection to the database (an

    >access
    >> mdb).
    >>
    >> I originally had a scheme where I was passing the object reference of

    the
    >> data dll to each of the other dll's. However, if I make the data dll

    >global
    >> multiuse, my understanding is that vb will create a global object and

    that
    >> anything running in the process, like all my other dll's, will have access
    >> to that instance of the object without having to set any explicit

    >references.
    >> The documentation is unclear on this so I tried it and it seems to work

    -
    >> only one connection is made and all the dll's that reference the data

    dll
    >> use the same connection. Has anyone else used a global multiuse object

    in
    >> this way? Is there any downside to this scheme (assuming all objects

    >remain
    >> in-process)?
    >>
    >> Randy

    >
    >



  4. #4
    Anand Guest

    Re: use of global multiuse


    I feel that your understanding of Global MultiUse Instancing is not correct.

    1.Multiuse makes sure that only one instance of the component is started
    WHICH CAN serve your requests for objects creation rather than starting one
    instance for every object creation requests.
    Here,you keep in mind two points,
    a)Surprisingly,One more instance of component is different from one more
    object creation.Thus,instancing is relevant for Components
    b)Every Object request will always loads a new object.


    2)Global MultiUse :-This Global means that you can directly access the methods
    and properties without having to directly create an object.BUT one object
    will automatically be created.
    There is no Global object generated on the component to serve different clients.


    3)You can refer MSDN which is clear in this.The important notes given there
    as follows

    a)Important The "global" in global objects refers to the fact that all
    of the objectís properties and methods are available in the global name space
    of your project. It does not mean that one object is automatically shared
    by all clients. Each client that uses your component gets its own global
    object.

    b)Note The properties and methods of a GlobalMultiUse object are not part
    of the global name space of the component that provides the object. For example,
    within a project that contains the GlobalUtility class, you must explicitly
    create an instance of GlobalUtility in order to use the object's properties
    and methods. Other limitations of global objects are listed in "Global Objects
    and Code Libraries," in "Building Code Components."

    Anand




    "Randy Baron" <rbaron@shrinenet.org> wrote:
    >
    >I am designing an app that will consist of a "shell" main form that will

    hold
    >ocx's for each of it's screens. Each ocx will have a corresponding dll holding
    >all the business logic. All data access will be routed through a dll that
    >will (among other things) hold the ado connection to the database (an access
    >mdb).
    >
    >I originally had a scheme where I was passing the object reference of the
    >data dll to each of the other dll's. However, if I make the data dll global
    >multiuse, my understanding is that vb will create a global object and that
    >anything running in the process, like all my other dll's, will have access
    >to that instance of the object without having to set any explicit references.
    >The documentation is unclear on this so I tried it and it seems to work

    -
    >only one connection is made and all the dll's that reference the data dll
    >use the same connection. Has anyone else used a global multiuse object in
    >this way? Is there any downside to this scheme (assuming all objects remain
    >in-process)?
    >
    >Randy



  5. #5
    Jim Deutch Guest

    Re: use of global multiuse

    Global Multiuse is analgous to "Dim As New". They create objects just like
    the objects created with regular Multiuse and "Dim As...Set = New": the
    distinction is that you've given over your control over when an instance is
    created (or not) to the VB automagician.

    I prefer to handle instancing myself, thank you.

    So, I never do "Dim X As New Y" and I never do Global Multiuse. I always
    Dim and Set my object variables explicitly in code.

    Jim Deutch

    Randy Baron wrote in message <392d1d03$1@news.devx.com>...
    >
    >I am designing an app that will consist of a "shell" main form that will

    hold
    >ocx's for each of it's screens. Each ocx will have a corresponding dll

    holding
    >all the business logic. All data access will be routed through a dll that
    >will (among other things) hold the ado connection to the database (an

    access
    >mdb).
    >
    >I originally had a scheme where I was passing the object reference of the
    >data dll to each of the other dll's. However, if I make the data dll global
    >multiuse, my understanding is that vb will create a global object and that
    >anything running in the process, like all my other dll's, will have access
    >to that instance of the object without having to set any explicit

    references.
    >The documentation is unclear on this so I tried it and it seems to work -
    >only one connection is made and all the dll's that reference the data dll
    >use the same connection. Has anyone else used a global multiuse object in
    >this way? Is there any downside to this scheme (assuming all objects remain
    >in-process)?
    >
    >Randy




  6. #6
    Randy Baron Guest

    Re: use of global multiuse


    Jim,

    Like you I prefer to keep control of my instancing. This is why I never really
    considered global multiuse before. However, if you specifically instantiate
    your objects, in order to share a specific instance of an object (ie data
    contained in that instance) you need to instantiate it and then pass it around.
    Indeed, this is what I had been doing. However, now, despite what the documentation
    says, I am apparantly sharing one instance of the global object among all
    of my dll's within a project group. Therefore no need to pass around references.
    The vb "automagician" creates it at first code reference, keeps it around
    as long as the reference count is >=1 and destroys when the reference count
    goes to zero.

    For instance (no pun intended), say a project group has 5 projects - an exe,
    an ocx and 4 dlls (dll1, dll2, dll3 and dll4 which is the global multiuse).
    Dll's 1, 2 and 3 have dll 4 checked in the project references list. Sub main
    instantiates dll1 which sets a property in the global multiuse object. No
    set statement, just a call to the let property to set an internal string
    data variable. This will instatiate the global object. Sub main then loads
    the main form which has the ocx sited on it. In the ocx's initialize I instantiate
    dll2. In the form load I instantiate dll3.

    Now the only dll that has set the property in the global multiuse object
    is Dll1. However, when either dll1 or 2 calls the get property for the value
    that was set by dll1 it will return the value set in dll1. Hence, each of
    these seperate projects is sharing the data of one object and I did not need
    to pass the object around.

    What I am trying to do is confirm that this behavior is correct. As noted
    in some of the previous posts, the documentation seems to indicate that each
    dll would get its own instance of the object. If my understanding is correct,
    this would mean in the above example that the property gets made by dll's
    2 and 3 would return empty strings. So, either I don't really understand
    how objects are instantiated or I am experiencing behavior contrary to what
    the documentation states. If its the former, I am hoping someone can explain
    it to me or point me to a reference other than Kurata or Appleman (both of
    whom mention global multiuse only in passing). If it is the later I am hoping
    someone else can confirm the behavior of a global multiuse object used in
    this fashion.

    Randy the Objectively Confused


    "Jim Deutch" <103134.3516@compuserve.com> wrote:
    >Global Multiuse is analgous to "Dim As New". They create objects just like
    >the objects created with regular Multiuse and "Dim As...Set = New": the
    >distinction is that you've given over your control over when an instance

    is
    >created (or not) to the VB automagician.
    >
    >I prefer to handle instancing myself, thank you.
    >
    >So, I never do "Dim X As New Y" and I never do Global Multiuse. I always
    >Dim and Set my object variables explicitly in code.
    >
    >Jim Deutch
    >
    >Randy Baron wrote in message <392d1d03$1@news.devx.com>...
    >>
    >>I am designing an app that will consist of a "shell" main form that will

    >hold
    >>ocx's for each of it's screens. Each ocx will have a corresponding dll

    >holding
    >>all the business logic. All data access will be routed through a dll that
    >>will (among other things) hold the ado connection to the database (an

    >access
    >>mdb).
    >>
    >>I originally had a scheme where I was passing the object reference of the
    >>data dll to each of the other dll's. However, if I make the data dll global
    >>multiuse, my understanding is that vb will create a global object and that
    >>anything running in the process, like all my other dll's, will have access
    >>to that instance of the object without having to set any explicit

    >references.
    >>The documentation is unclear on this so I tried it and it seems to work

    -
    >>only one connection is made and all the dll's that reference the data dll
    >>use the same connection. Has anyone else used a global multiuse object

    in
    >>this way? Is there any downside to this scheme (assuming all objects remain
    >>in-process)?
    >>
    >>Randy

    >
    >



  7. #7
    Mark Alexander Bertenshaw Guest

    Re: use of global multiuse

    Jim -

    I would generally agree with your views, but I think there are two instances
    where Global MultiUse is useful:

    * When you are creating "factory" methods to obtain new instances of your
    classes.
    * When you are moving code from a BAS module to a component, and don't want
    to rewrite any code.

    --

    ---------------------------------------
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Prime Response
    Brentford
    UK

    "Jim Deutch" <103134.3516@compuserve.com> wrote in message
    news:3933ecb3@news.devx.com...
    > Global Multiuse is analgous to "Dim As New". They create objects just

    like
    > the objects created with regular Multiuse and "Dim As...Set = New": the
    > distinction is that you've given over your control over when an instance

    is
    > created (or not) to the VB automagician.
    >
    > I prefer to handle instancing myself, thank you.
    >
    > So, I never do "Dim X As New Y" and I never do Global Multiuse. I always
    > Dim and Set my object variables explicitly in code.
    >
    > Jim Deutch
    >
    > Randy Baron wrote in message <392d1d03$1@news.devx.com>...
    > >
    > >I am designing an app that will consist of a "shell" main form that will

    > hold
    > >ocx's for each of it's screens. Each ocx will have a corresponding dll

    > holding
    > >all the business logic. All data access will be routed through a dll that
    > >will (among other things) hold the ado connection to the database (an

    > access
    > >mdb).
    > >
    > >I originally had a scheme where I was passing the object reference of the
    > >data dll to each of the other dll's. However, if I make the data dll

    global
    > >multiuse, my understanding is that vb will create a global object and

    that
    > >anything running in the process, like all my other dll's, will have

    access
    > >to that instance of the object without having to set any explicit

    > references.
    > >The documentation is unclear on this so I tried it and it seems to work -
    > >only one connection is made and all the dll's that reference the data dll
    > >use the same connection. Has anyone else used a global multiuse object in
    > >this way? Is there any downside to this scheme (assuming all objects

    remain
    > >in-process)?
    > >
    > >Randy

    >
    >




  8. #8
    Beginner Guest

    Re: use of global multiuse


    Hi,

    I never read any documentation about global-multiuse. From my experience,
    defintely each dll gets its own instance of the object.

    "Randy Baron" <rbaron@shrinenet.org> wrote:
    >
    >Jim,
    >
    >Like you I prefer to keep control of my instancing. This is why I never

    really
    >considered global multiuse before. However, if you specifically instantiate
    >your objects, in order to share a specific instance of an object (ie data
    >contained in that instance) you need to instantiate it and then pass it

    around.
    >Indeed, this is what I had been doing. However, now, despite what the documentation
    >says, I am apparantly sharing one instance of the global object among all
    >of my dll's within a project group. Therefore no need to pass around references.
    >The vb "automagician" creates it at first code reference, keeps it around
    >as long as the reference count is >=1 and destroys when the reference count
    >goes to zero.
    >
    >For instance (no pun intended), say a project group has 5 projects - an

    exe,
    >an ocx and 4 dlls (dll1, dll2, dll3 and dll4 which is the global multiuse).
    >Dll's 1, 2 and 3 have dll 4 checked in the project references list. Sub

    main
    >instantiates dll1 which sets a property in the global multiuse object. No
    >set statement, just a call to the let property to set an internal string
    >data variable. This will instatiate the global object. Sub main then loads
    >the main form which has the ocx sited on it. In the ocx's initialize I instantiate
    >dll2. In the form load I instantiate dll3.
    >
    >Now the only dll that has set the property in the global multiuse object
    >is Dll1. However, when either dll1 or 2 calls the get property for the value
    >that was set by dll1 it will return the value set in dll1. Hence, each of
    >these seperate projects is sharing the data of one object and I did not

    need
    >to pass the object around.
    >
    >What I am trying to do is confirm that this behavior is correct. As noted
    >in some of the previous posts, the documentation seems to indicate that

    each
    >dll would get its own instance of the object. If my understanding is correct,
    >this would mean in the above example that the property gets made by dll's
    >2 and 3 would return empty strings. So, either I don't really understand
    >how objects are instantiated or I am experiencing behavior contrary to what
    >the documentation states. If its the former, I am hoping someone can explain
    >it to me or point me to a reference other than Kurata or Appleman (both

    of
    >whom mention global multiuse only in passing). If it is the later I am hoping
    >someone else can confirm the behavior of a global multiuse object used in
    >this fashion.
    >
    >Randy the Objectively Confused
    >
    >
    >"Jim Deutch" <103134.3516@compuserve.com> wrote:
    >>Global Multiuse is analgous to "Dim As New". They create objects just

    like
    >>the objects created with regular Multiuse and "Dim As...Set = New": the
    >>distinction is that you've given over your control over when an instance

    >is
    >>created (or not) to the VB automagician.
    >>
    >>I prefer to handle instancing myself, thank you.
    >>
    >>So, I never do "Dim X As New Y" and I never do Global Multiuse. I always
    >>Dim and Set my object variables explicitly in code.
    >>
    >>Jim Deutch
    >>
    >>Randy Baron wrote in message <392d1d03$1@news.devx.com>...
    >>>
    >>>I am designing an app that will consist of a "shell" main form that will

    >>hold
    >>>ocx's for each of it's screens. Each ocx will have a corresponding dll

    >>holding
    >>>all the business logic. All data access will be routed through a dll that
    >>>will (among other things) hold the ado connection to the database (an

    >>access
    >>>mdb).
    >>>
    >>>I originally had a scheme where I was passing the object reference of

    the
    >>>data dll to each of the other dll's. However, if I make the data dll global
    >>>multiuse, my understanding is that vb will create a global object and

    that
    >>>anything running in the process, like all my other dll's, will have access
    >>>to that instance of the object without having to set any explicit

    >>references.
    >>>The documentation is unclear on this so I tried it and it seems to work

    >-
    >>>only one connection is made and all the dll's that reference the data

    dll
    >>>use the same connection. Has anyone else used a global multiuse object

    >in
    >>>this way? Is there any downside to this scheme (assuming all objects remain
    >>>in-process)?
    >>>
    >>>Randy

    >>
    >>

    >



  9. #9
    Colin McGuigan Guest

    Re: use of global multiuse

    Beginner wrote in message <396cdc96$1@news.devx.com>...
    >
    >Hi,
    >
    >I never read any documentation about global-multiuse. From my experience,
    >defintely each dll gets its own instance of the object.



    Not to tread on the toes of 'Beginner', but...

    Re: Sharing data via a GlobalMultiUse class module:

    I'm not sure if each DLL would get a different instance of the
    GlobalMultiUse class or not, but, as long as they were all within the same
    process (and DLLs are always in process, assuming they're all on the same
    machine), they would _definitely_ get the same instance of the DLL.

    Therefore, what I do when I want to share data between many components in
    the same process is to put said data into a BAS module, and have a class
    (GlobalMultiUse or not) wrap the BAS module.

    Ie, if I have my referenced DLL as so:

    'BAS module

    Public g_strData As String

    'CLS GlobalMultiUse module CTest

    Public Property Get DLLData() As String
    DLLData = g_strData
    End Property

    Public Property Let DLLData(ByVal newDLLData As String)
    g_strData = newDLLData
    End Property

    Then in any of my components that references said DLL, I could use either
    'DLLData' (because it's GlobalMultiUse), or actually instanciate a CTest
    object and use it's .DLLData property, and it would all point towards the
    same string.

    --
    Colin McGuigan




  10. #10
    Michael Culley Guest

    Re: use of global multiuse


    Randy,

    >The vb "automagician" creates it at first code reference, keeps it around
    >as long as the reference count is >=1 and destroys when the reference count
    >goes to zero.


    Won't this only be when the app finishes?

    Michael Culley

    "Randy Baron" <rbaron@shrinenet.org> wrote:
    >
    >Jim,
    >
    >Like you I prefer to keep control of my instancing. This is why I never

    really
    >considered global multiuse before. However, if you specifically instantiate
    >your objects, in order to share a specific instance of an object (ie data
    >contained in that instance) you need to instantiate it and then pass it

    around.
    >Indeed, this is what I had been doing. However, now, despite what the documentation
    >says, I am apparantly sharing one instance of the global object among all
    >of my dll's within a project group. Therefore no need to pass around references.
    >The vb "automagician" creates it at first code reference, keeps it around
    >as long as the reference count is >=1 and destroys when the reference count
    >goes to zero.
    >
    >For instance (no pun intended), say a project group has 5 projects - an

    exe,
    >an ocx and 4 dlls (dll1, dll2, dll3 and dll4 which is the global multiuse).
    >Dll's 1, 2 and 3 have dll 4 checked in the project references list. Sub

    main
    >instantiates dll1 which sets a property in the global multiuse object. No
    >set statement, just a call to the let property to set an internal string
    >data variable. This will instatiate the global object. Sub main then loads
    >the main form which has the ocx sited on it. In the ocx's initialize I instantiate
    >dll2. In the form load I instantiate dll3.
    >
    >Now the only dll that has set the property in the global multiuse object
    >is Dll1. However, when either dll1 or 2 calls the get property for the value
    >that was set by dll1 it will return the value set in dll1. Hence, each of
    >these seperate projects is sharing the data of one object and I did not

    need
    >to pass the object around.
    >
    >What I am trying to do is confirm that this behavior is correct. As noted
    >in some of the previous posts, the documentation seems to indicate that

    each
    >dll would get its own instance of the object. If my understanding is correct,
    >this would mean in the above example that the property gets made by dll's
    >2 and 3 would return empty strings. So, either I don't really understand
    >how objects are instantiated or I am experiencing behavior contrary to what
    >the documentation states. If its the former, I am hoping someone can explain
    >it to me or point me to a reference other than Kurata or Appleman (both

    of
    >whom mention global multiuse only in passing). If it is the later I am hoping
    >someone else can confirm the behavior of a global multiuse object used in
    >this fashion.
    >
    >Randy the Objectively Confused
    >
    >
    >"Jim Deutch" <103134.3516@compuserve.com> wrote:
    >>Global Multiuse is analgous to "Dim As New". They create objects just

    like
    >>the objects created with regular Multiuse and "Dim As...Set = New": the
    >>distinction is that you've given over your control over when an instance

    >is
    >>created (or not) to the VB automagician.
    >>
    >>I prefer to handle instancing myself, thank you.
    >>
    >>So, I never do "Dim X As New Y" and I never do Global Multiuse. I always
    >>Dim and Set my object variables explicitly in code.
    >>
    >>Jim Deutch
    >>
    >>Randy Baron wrote in message <392d1d03$1@news.devx.com>...
    >>>
    >>>I am designing an app that will consist of a "shell" main form that will

    >>hold
    >>>ocx's for each of it's screens. Each ocx will have a corresponding dll

    >>holding
    >>>all the business logic. All data access will be routed through a dll that
    >>>will (among other things) hold the ado connection to the database (an

    >>access
    >>>mdb).
    >>>
    >>>I originally had a scheme where I was passing the object reference of

    the
    >>>data dll to each of the other dll's. However, if I make the data dll global
    >>>multiuse, my understanding is that vb will create a global object and

    that
    >>>anything running in the process, like all my other dll's, will have access
    >>>to that instance of the object without having to set any explicit

    >>references.
    >>>The documentation is unclear on this so I tried it and it seems to work

    >-
    >>>only one connection is made and all the dll's that reference the data

    dll
    >>>use the same connection. Has anyone else used a global multiuse object

    >in
    >>>this way? Is there any downside to this scheme (assuming all objects remain
    >>>in-process)?
    >>>
    >>>Randy

    >>
    >>

    >



  11. #11
    Beginner Guest

    Re: use of global multiuse


    Hi, Seems to be rude. I think here it is not right place.

    If you understand the theroy of COM in VB, you can get the point.
    That is why you have to put the shared data in the .BAS module which is shared
    by each instance. If all DLL even in the same process have the same instance,
    why you do that? now you should find an easy way to figure it out

    "Colin McGuigan" <colin@chicor.com> wrote:
    >Beginner wrote in message <396cdc96$1@news.devx.com>...
    >>
    >>Hi,
    >>
    >>I never read any documentation about global-multiuse. From my experience,
    >>defintely each dll gets its own instance of the object.

    >
    >
    >Not to tread on the toes of 'Beginner', but...
    >
    >Re: Sharing data via a GlobalMultiUse class module:
    >
    >I'm not sure if each DLL would get a different instance of the
    >GlobalMultiUse class or not, but, as long as they were all within the same
    >process (and DLLs are always in process, assuming they're all on the same
    >machine), they would _definitely_ get the same instance of the DLL.
    >
    >Therefore, what I do when I want to share data between many components in
    >the same process is to put said data into a BAS module, and have a class
    >(GlobalMultiUse or not) wrap the BAS module.
    >
    >Ie, if I have my referenced DLL as so:
    >
    >'BAS module
    >
    >Public g_strData As String
    >
    >'CLS GlobalMultiUse module CTest
    >
    >Public Property Get DLLData() As String
    > DLLData = g_strData
    >End Property
    >
    >Public Property Let DLLData(ByVal newDLLData As String)
    > g_strData = newDLLData
    >End Property
    >
    >Then in any of my components that references said DLL, I could use either
    >'DLLData' (because it's GlobalMultiUse), or actually instanciate a CTest
    >object and use it's .DLLData property, and it would all point towards the
    >same string.
    >
    >--
    >Colin McGuigan
    >
    >
    >



  12. #12
    Colin McGuigan Guest

    Re: use of global multiuse

    Beginner wrote in message <396dcafc$1@news.devx.com>...
    >
    >Hi, Seems to be rude. I think here it is not right place.
    >
    >If you understand the theroy of COM in VB, you can get the point.
    >That is why you have to put the shared data in the .BAS module which is

    shared
    >by each instance. If all DLL even in the same process have the same

    instance,
    >why you do that? now you should find an easy way to figure it out


    I tried, but I couldn't parse this. Want to try again?


    --
    Colin McGuigan




  13. #13
    Beginner Guest

    Re: use of global multiuse


    "Colin McGuigan" <colin@chicor.com> wrote:
    >Beginner wrote in message <396dcafc$1@news.devx.com>...
    >>
    >>Hi, Seems to be rude. I think here it is not right place.
    >>
    >>If you understand the theroy of COM in VB, you can get the point.
    >>That is why you have to put the shared data in the .BAS module which is

    >shared
    >>by each instance. If all DLL even in the same process have the same

    >instance,
    >>why you do that? now you should find an easy way to figure it out

    >


    >I tried, but I couldn't parse this. Want to try again?
    >
    >
    >--
    >Colin McGuigan
    >
    >
    >


    Assume Class A in A.DLL, and Class B in B.DLL and class C in C.DLL. A is
    global-multiuse, B and C both use A by reference to A.DLL. And then you
    create a project P which use A,B,C.

    Compile P, run it. do not run it in debug mode or VB IDE

    When you create A.DLL, add a module which define a varible, ObjectCount:

    Public ObjectCount as integer

    A's class_initialize looks like

    Sub class_initialize()

    ObjectCount= ObjectCount+1
    MsgBox "ObjectCount=" & ObjectCount

    End Sub

    Note that in P,B,C, you must access a A's method or property

    run P to see what will happen.





  14. #14
    Colin McGuigan Guest

    Re: use of global multiuse

    Beginner wrote in message <396de8f2$1@news.devx.com>...
    <snip>
    >run P to see what will happen.


    Why? What are you trying to prove or have me see here?

    As it is, nothing will happen because Class A will never get instantiated
    because nothing ever references it. GlobalMultiUse classes do not have
    their Class_Initialize called until they're first invoked (much like
    variables created 'Dim blah As New CBlah')

    If your point is that you should put such (process-wide) variables into a
    BAS file, then I'm confused, because that's what I said originally.


    --
    Colin McGuigan




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center