Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Make instant of a Class persistent for whole session.

Discussion in 'Information Technology' started by sime, Jul 28, 2006.

  1. sime

    sime
    Expand Collapse
    Guest

    Hello

    When my database opens, I use Autoexec to run a function. In that
    function I want to instantiate a class and have that instance remain
    accessible for the whole session.

    Specifically I am using the class to make variables efficiently
    available to any other code.

    I can do this with a form that hides itself - is that the only way to
    do this? It seems a bit silly, but hey if that's the way I should do it
    I won't complain. :)

    Thanks
    Simon
     
  2. Loading...


  3. Tom Wickerath

    Tom Wickerath
    Expand Collapse
    Guest

    Hi Simon,

    Why can't you just declare the variables that you wish to persist as
    globals, and set their value in the function that you run from your autoexec
    macro. I really don't see the need to instantiate a class to accomplish this
    goal. Something like this for determining the users NTUserID, and storing it
    in the global variable named gstrUserName. Then just call the fOSUserName
    function from your Autoexec macro.


    Module name: basUtilities
    Within this module:

    ' Get Login name
    ' http://www.mvps.org/access/api/api0008.htm

    Option Compare Database
    Option Explicit

    Private Declare Function apiGetUserName Lib "advapi32.dll" Alias _
    "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long

    Public gstrUserName As String

    Function fOSUserName() As String
    On Error GoTo ProcError

    Dim lngLen As Long, lngX As Long
    Dim strUserName As String

    strUserName = String$(254, 0)
    lngLen = 255
    lngX = apiGetUserName(strUserName, lngLen)
    If (lngX > 0) Then
    fOSUserName = Left$(strUserName, lngLen - 1)
    Else
    fOSUserName = vbNullString
    End If

    gstrUserName = fOSUserName

    ExitProc:
    Exit Function
    ProcError:
    MsgBox "Error " & Err.Number & ": " & Err.Description, _
    vbCritical, "Error in procedure fOSUserName..."
    gstrUserName = "Unknown"
    Resume ExitProc
    End Function



    Tom Wickerath
    Microsoft Access MVP

    http://www.access.qbuilt.com/html/expert_contributors.html
    http://www.access.qbuilt.com/html/search.html
    __________________________________________


    "sime" wrote:

    > Hello
    >
    > When my database opens, I use Autoexec to run a function. In that
    > function I want to instantiate a class and have that instance remain
    > accessible for the whole session.
    >
    > Specifically I am using the class to make variables efficiently
    > available to any other code.
    >
    > I can do this with a form that hides itself - is that the only way to
    > do this? It seems a bit silly, but hey if that's the way I should do it
    > I won't complain. :)
    >
    > Thanks
    > Simon
    >
    >
     
  4. sime

    sime
    Expand Collapse
    Guest

    Yes, that does the trick. And it works with Objects.

    I had tried "Global" inside the class module, and I had tried your
    suggestion with with things like "Static" and "Global Static". So
    close!

    Thanks heaps
    Simon


    Tom Wickerath wrote:
    > Hi Simon,
    >
    > Why can't you just declare the variables that you wish to persist as
    > globals, and set their value in the function that you run from your autoexec
    > macro.
     
  5. Tom Wickerath

    Tom Wickerath
    Expand Collapse
    Guest

    Hi Simon,

    You're welcome.

    The only other thing you might do, just to help ensure that your global
    variable will always have a value, is to use the Len function to ensure this
    just prior to an attempt to reference it. Later versions of Access have been
    much better than earlier versions about not losing global variables, however,
    it is possible to lose the value if you are working in the Visual Basic
    Environment, or it may not have been set in the first place if you opened
    your database with the Shift key depressed in order to bypass the Autoexec
    file. Here is an example:

    If Len(gstrUserName) = 0 Then
    fOSUserName ' Reinitialize value
    End If

    Select Case gstrUserName
    Case blahblahblah
    Do this
    Case Else
    Do that
    End Select

    This way, if the test for the length of your global variable is zero, a call
    is made to re-initialize it just prior to attempting to do something with it,
    such as Select Case.


    Tom Wickerath
    Microsoft Access MVP

    http://www.access.qbuilt.com/html/expert_contributors.html
    http://www.access.qbuilt.com/html/search.html
    __________________________________________

    "sime" wrote:

    > Yes, that does the trick. And it works with Objects.
    >
    > I had tried "Global" inside the class module, and I had tried your
    > suggestion with with things like "Static" and "Global Static". So
    > close!
    >
    > Thanks heaps
    > Simon
     
  6. sime

    sime
    Expand Collapse
    Guest

    Hehe, I came across this issue only an hour later. I was wondering if
    there were any circumstances where the Global would lose it's value and
    a bit of searching revealed that it can happen quite easily unless you
    are careful with error handling (which I'm not) or creating an MDE
    (which I'm not).

    I have decided to take the "easy" option and have a hidden form. And
    while I'm there I've turned it into a variable viewer and made it
    visible during development.


    Tom Wickerath wrote:
    > Hi Simon,
    >
    > You're welcome.
    >
    > The only other thing you might do, just to help ensure that your global
    > variable will always have a value, is to use the Len function to ensure this
    > just prior to an attempt to reference it. Later versions of Access have been
    > much better than earlier versions about not losing global variables, however,
    > it is possible to lose the value if you are working in the Visual Basic
    > Environment, or it may not have been set in the first place if you opened
    > your database with the Shift key depressed in order to bypass the Autoexec
    > file. Here is an example:
    >
     
  7. Smartin

    Smartin
    Expand Collapse
    Guest

    sime wrote:
    > Hello
    >
    > When my database opens, I use Autoexec to run a function. In that
    > function I want to instantiate a class and have that instance remain
    > accessible for the whole session.
    >
    > Specifically I am using the class to make variables efficiently
    > available to any other code.
    >
    > I can do this with a form that hides itself - is that the only way to
    > do this? It seems a bit silly, but hey if that's the way I should do it
    > I won't complain. :)
    >
    > Thanks
    > Simon
    >


    I might be missing something, but what about instantiating the class at
    the top of the module in which the function is called? This assumes the
    function is in a standard module.

    Module MyMod
    ============
    Option Compare Database
    Option Explicit

    Set TheClass = New MyClass
    ------------------------------
    Function AutoexecFunction()
    blah blah blah
    End Function

    Don't forget to Set TheClass = Nothing before you close everything up.

    --
    Smartin
     
  8. Dirk Goldgar

    Dirk Goldgar
    Expand Collapse
    Guest

    "Smartin" <smartin108@yahoo.com> wrote in message
    news:K7KdnarfULdc7FjZnZ2dnUVZ_o2dnZ2d@giganews.com
    >
    > I might be missing something, but what about instantiating the class
    > at the top of the module in which the function is called? This
    > assumes the function is in a standard module.
    >
    > Module MyMod
    > ============
    > Option Compare Database
    > Option Explicit
    >
    > Set TheClass = New MyClass
    > ------------------------------
    > Function AutoexecFunction()
    > blah blah blah
    > End Function
    >
    > Don't forget to Set TheClass = Nothing before you close everything up.


    Won't work. Executable statements must be enclosed in procedures; they
    can't just sit at the top of a module. And if they could, what event
    would cause them to be executed?

    --
    Dirk Goldgar, MS Access MVP
    www.datagnostics.com

    (please reply to the newsgroup)
     
  9. Smartin

    Smartin
    Expand Collapse
    Guest

    Dirk Goldgar wrote:
    > "Smartin" <smartin108@yahoo.com> wrote in message
    > news:K7KdnarfULdc7FjZnZ2dnUVZ_o2dnZ2d@giganews.com
    >> I might be missing something, but what about instantiating the class
    >> at the top of the module in which the function is called? This
    >> assumes the function is in a standard module.
    >>
    >> Module MyMod
    >> ============
    >> Option Compare Database
    >> Option Explicit
    >>
    >> Set TheClass = New MyClass
    >> ------------------------------
    >> Function AutoexecFunction()
    >> blah blah blah
    >> End Function
    >>
    >> Don't forget to Set TheClass = Nothing before you close everything up.

    >
    > Won't work. Executable statements must be enclosed in procedures; they
    > can't just sit at the top of a module. And if they could, what event
    > would cause them to be executed?
    >


    I thought I was doing something similar at work, but I will check the
    code tomorrow to be sure and clarify or withdraw my proposition. Thanks
    for the heads-up.

    --
    Smartin
     
  10. Smartin

    Smartin
    Expand Collapse
    Guest

    Smartin wrote:
    > Dirk Goldgar wrote:
    >> "Smartin" <smartin108@yahoo.com> wrote in message
    >> news:K7KdnarfULdc7FjZnZ2dnUVZ_o2dnZ2d@giganews.com
    >>> I might be missing something, but what about instantiating the class
    >>> at the top of the module in which the function is called? This
    >>> assumes the function is in a standard module.
    >>>
    >>> Module MyMod
    >>> ============
    >>> Option Compare Database
    >>> Option Explicit
    >>>
    >>> Set TheClass = New MyClass
    >>> ------------------------------
    >>> Function AutoexecFunction()
    >>> blah blah blah
    >>> End Function
    >>>
    >>> Don't forget to Set TheClass = Nothing before you close everything up.

    >>
    >> Won't work. Executable statements must be enclosed in procedures; they
    >> can't just sit at the top of a module. And if they could, what event
    >> would cause them to be executed?
    >>

    >
    > I thought I was doing something similar at work, but I will check the
    > code tomorrow to be sure and clarify or withdraw my proposition. Thanks
    > for the heads-up.
    >


    My error, the declaration I am using is actually

    Option Compare Database
    Option Explicit

    Public TheClass As New MyClass
    --------------------------------------

    Works great. The class is accessible to other modules and forms.

    --
    Smartin
     
  11. sime

    sime
    Expand Collapse
    Guest

    That is in a normal module I am guessing. Won't "TheClass" die once the
    code finishes executing?


    Smartin wrote:

    > > I thought I was doing something similar at work, but I will check the
    > > code tomorrow to be sure and clarify or withdraw my proposition. Thanks
    > > for the heads-up.
    > >

    >
    > My error, the declaration I am using is actually
    >
    > Option Compare Database
    > Option Explicit
    >
    > Public TheClass As New MyClass
    > --------------------------------------
    >
    > Works great. The class is accessible to other modules and forms.
    >
    > --
    > Smartin
     
  12. Smartin

    Smartin
    Expand Collapse
    Guest

    sime wrote:
    > That is in a normal module I am guessing. Won't "TheClass" die once the
    > code finishes executing?
    >
    >
    > Smartin wrote:
    >
    >>> I thought I was doing something similar at work, but I will check the
    >>> code tomorrow to be sure and clarify or withdraw my proposition. Thanks
    >>> for the heads-up.
    >>>

    >> My error, the declaration I am using is actually
    >>
    >> Option Compare Database
    >> Option Explicit
    >>
    >> Public TheClass As New MyClass
    >> --------------------------------------
    >>
    >> Works great. The class is accessible to other modules and forms.
    >>
    >> --
    >> Smartin

    >


    Yes, the declaration is in a normal module. Without meaning to be
    argumentative, explain when should object TheClass die? The module does
    not "close". It merely exists, and no code is fired to instantiate the
    object. In better days I could probably have given a better explanation.
    I hope this makes sense.

    I will look into this a little further to be sure, but AFAICT the
    instantiation of the class persists as long as the application is open.

    Kind Regards,
    --
    Smartin
     
  13. Smartin

    Smartin
    Expand Collapse
    Guest

    Smartin wrote:
    > sime wrote:
    >> That is in a normal module I am guessing. Won't "TheClass" die once the
    >> code finishes executing?
    >>
    >>
    >> Smartin wrote:
    >>
    >>>> I thought I was doing something similar at work, but I will check the
    >>>> code tomorrow to be sure and clarify or withdraw my proposition. Thanks
    >>>> for the heads-up.
    >>>>
    >>> My error, the declaration I am using is actually
    >>>
    >>> Option Compare Database
    >>> Option Explicit
    >>>
    >>> Public TheClass As New MyClass
    >>> --------------------------------------
    >>>
    >>> Works great. The class is accessible to other modules and forms.
    >>>
    >>> --
    >>> Smartin

    >>

    >
    > Yes, the declaration is in a normal module. Without meaning to be
    > argumentative, explain when should object TheClass die? The module does
    > not "close". It merely exists, and no code is fired to instantiate the
    > object. In better days I could probably have given a better explanation.
    > I hope this makes sense.
    >
    > I will look into this a little further to be sure, but AFAICT the
    > instantiation of the class persists as long as the application is open.
    >
    > Kind Regards,


    Just to follow up and (hopefully) clarify, a publicly declared object is
    accessible to the application for the life of the application. Unless,
    of course, you set the object to Nothing.

    Think of a publicly declared variable. It doesn't go away even though
    the code asking for it is in another class/form/module.

    Getting off topic somewhat, I would be interested to hear comments on
    the virtues and pitfalls of using a class vs. a collection of variables
    and functions in a module.

    Personally, when I have a group of processes I want to apply to a
    "thing" I like to create a class for it. I can swiftly reuse the code if
    I need to use the "thing" in another application -- I simply drop in its
    class module.

    In the long run I find it is much easier to have the thing's methods and
    properties on hand by typing a dot, rather than try to recall what Subs
    and Functions are available. Plus, if I want to have multiple "things"
    at the same time, a class makes this a snap.

    For instance one "thing" I've been reusing quite a bit lately is
    basically a text container I use to build up email messages in Access.
    VBA and A97 do not provide a very robust collection of text manipulation
    features, so I built functionality into the class like search and
    replace, a tabulation mechanism for aligning columns of data, append,
    automatic insertion of CrLf, etc. This reduces the amount of code I have
    to write later -- and cleans up the code considerably.

    HTH
    --
    Smartin
     
  14. sime

    sime
    Expand Collapse
    Guest

    OOP is quite cool of course. Encapsulation and modulation.

    Regarding Global/Public variables, I found I was losing the values I'd
    assigned. The reason for these are better described by others (see
    link). Maybe you could comment on the difference in your approach.
    http://groups.google.com.au/groups?...81&as_maxd=27&as_maxm=1&as_maxy=2006&safe=off

    ..s


    Smartin wrote:

    > >
    > > Yes, the declaration is in a normal module. Without meaning to be
    > > argumentative, explain when should object TheClass die? The module does
    > > not "close". It merely exists, and no code is fired to instantiate the
    > > object. In better days I could probably have given a better explanation.
    > > I hope this makes sense.
    > >
    > > I will look into this a little further to be sure, but AFAICT the
    > > instantiation of the class persists as long as the application is open.
    > >
    > > Kind Regards,

    >
    > Just to follow up and (hopefully) clarify, a publicly declared object is
    > accessible to the application for the life of the application. Unless,
    > of course, you set the object to Nothing.
    >
    > Think of a publicly declared variable. It doesn't go away even though
    > the code asking for it is in another class/form/module.
    >
    > Getting off topic somewhat, I would be interested to hear comments on
    > the virtues and pitfalls of using a class vs. a collection of variables
    > and functions in a module.
    >
    > Personally, when I have a group of processes I want to apply to a
    > "thing" I like to create a class for it. I can swiftly reuse the code if
    > I need to use the "thing" in another application -- I simply drop in its
    > class module.
    >
    > In the long run I find it is much easier to have the thing's methods and
    > properties on hand by typing a dot, rather than try to recall what Subs
    > and Functions are available. Plus, if I want to have multiple "things"
    > at the same time, a class makes this a snap.
    >
    > For instance one "thing" I've been reusing quite a bit lately is
    > basically a text container I use to build up email messages in Access.
    > VBA and A97 do not provide a very robust collection of text manipulation
    > features, so I built functionality into the class like search and
    > replace, a tabulation mechanism for aligning columns of data, append,
    > automatic insertion of CrLf, etc. This reduces the amount of code I have
    > to write later -- and cleans up the code considerably.
    >
    > HTH
    > --
    > Smartin
     

Share This Page