By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,347 Members | 2,120 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,347 IT Pros & Developers. It's quick & easy.

Maintain Reference to Session-Scope Instance

P: n/a
I have a "Tracker" class that registers "Messenger" classes to allow distribution of
unicast and broadcast messages between instances.

In code a reference to the Tracker class instance is retrieved via code in a module so
that anyone can access the Tracker methods. The module code:

Private m_objTracker As clsTracker

Public Function getTracker() As Object

If m_objTracker Is Nothing Then
Set m_objTracker = New clsTracker
End If

Set getTracker = m_objTracker

End Function

Kind of a Singleton self-healing proc however Tracker maintans multiple references to
instances of the Messenger class. An unhandled error will clear the m_objTracker variable
and orphan instances of the Messenger class.

Implementing good error handling would prevent the opportunity for variable reset by the
user and I believe an .MDE sidesteps this problem but I'm curious if there is a better way
to persist a class reference. Perhaps to a table or property?

I could obviously try this myself but was more interested in the experiences and opinions
of others as I contemplate the design issue. How are you handling session scoped object
references?

I could put this in an ActiveX .dll and use a COM solution but I want to explore a native
solution first.

Thoughts?

--
'---------------
'John Mishefske
'---------------
Aug 13 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
John Mishefske wrote:
I have a "Tracker" class that registers "Messenger" classes to allow
distribution of unicast and broadcast messages between instances.

In code a reference to the Tracker class instance is retrieved via code
in a module so that anyone can access the Tracker methods. The module code:

Private m_objTracker As clsTracker

Public Function getTracker() As Object

If m_objTracker Is Nothing Then
Set m_objTracker = New clsTracker
End If

Set getTracker = m_objTracker

End Function

Kind of a Singleton self-healing proc however Tracker maintans multiple
references to instances of the Messenger class. An unhandled error will
clear the m_objTracker variable and orphan instances of the Messenger
class.

Implementing good error handling would prevent the opportunity for
variable reset by the user and I believe an .MDE sidesteps this problem
but I'm curious if there is a better way to persist a class reference.
Perhaps to a table or property?

I could obviously try this myself but was more interested in the
experiences and opinions of others as I contemplate the design issue.
How are you handling session scoped object references?

I could put this in an ActiveX .dll and use a COM solution but I want to
explore a native solution first.

Thoughts?
Sometimes just posted a question spurs ideas. I could use a startup hidden form to create
a reference to the Tracker class and then use a Public Function in that startup form to
return an object reference to the Tracker instance.

--
'---------------
'John Mishefske
'---------------
Aug 13 '06 #2

P: n/a

John Mishefske wrote:
I have a "Tracker" class that registers "Messenger" classes to allow distribution of
unicast and broadcast messages between instances.

In code a reference to the Tracker class instance is retrieved via code in a module so
that anyone can access the Tracker methods. The module code:

Private m_objTracker As clsTracker

Public Function getTracker() As Object

If m_objTracker Is Nothing Then
Set m_objTracker = New clsTracker
End If

Set getTracker = m_objTracker

End Function

Kind of a Singleton self-healing proc however Tracker maintans multiple references to
instances of the Messenger class. An unhandled error will clear the m_objTracker variable
and orphan instances of the Messenger class.

Implementing good error handling would prevent the opportunity for variable reset by the
user and I believe an .MDE sidesteps this problem but I'm curious if there is a better way
to persist a class reference. Perhaps to a table or property?

I could obviously try this myself but was more interested in the experiences and opinions
of others as I contemplate the design issue. How are you handling session scoped object
references?

I could put this in an ActiveX .dll and use a COM solution but I want to explore a native
solution first.

Thoughts?

--
'---------------
'John Mishefske
'---------------
Aug 13 '06 #3

P: n/a
John Mishefske wrote:
Sometimes just posted a question spurs ideas. I could use a startup hidden form to create
a reference to the Tracker class and then use a Public Function in that startup form to
return an object reference to the Tracker instance.
Such a Form is a Class (assuming its HasModule property is true, or
that it has a module).

Why not just put the required Properties and Methods into the Form
Module?

A form has global scope by default. If the Form gets closed then it's
still in scope, one just
Form_FormName.SomeProperty
or
Form_FormName.SomeMethod
and it reopens. (But if it's already open it doesn't).

and of course, such a class does not have to be explicitly set to
nothing. When the appliccation closes, it closes and its OnClose Event
code is run.

and, of course, by messing with its visible, size and location
properties, it can be "flashed" to show messages.

and, of course, it has a built in timer.

If you need multiple instances of the Class (not multiple instances of
something within the class) I guess you would have to create and
maintain multiple instances of the form, but that's no different than
creating and maintaining multiple instances of a Class.

Resource? I can't notice any difference between using a hidden form and
using a class.

Aug 13 '06 #4

P: n/a
Lyle Fairfield wrote:
John Mishefske wrote:

>>Sometimes just posted a question spurs ideas. I could use a startup hidden form to create
a reference to the Tracker class and then use a Public Function in that startup form to
return an object reference to the Tracker instance.


Such a Form is a Class (assuming its HasModule property is true, or
that it has a module).

Why not just put the required Properties and Methods into the Form
Module?

A form has global scope by default. If the Form gets closed then it's
still in scope, one just
Form_FormName.SomeProperty
or
Form_FormName.SomeMethod
and it reopens. (But if it's already open it doesn't).

and of course, such a class does not have to be explicitly set to
nothing. When the appliccation closes, it closes and its OnClose Event
code is run.

and, of course, by messing with its visible, size and location
properties, it can be "flashed" to show messages.

and, of course, it has a built in timer.

If you need multiple instances of the Class (not multiple instances of
something within the class) I guess you would have to create and
maintain multiple instances of the form, but that's no different than
creating and maintaining multiple instances of a Class.

Resource? I can't notice any difference between using a hidden form and
using a class.
OK, thanks. Sounds like a better solution that I'll try.

--
'---------------
'John Mishefske
'---------------
Aug 14 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.