David,
You can mimic what the GW Toolkit does: instantiate copies of classes as
objects, and share them through the SharedObjects object.
For example, perhaps you have a set of functions that you use in almost
every app you develop. You would start by creating a global app that
contains a class that holds all the functions you need. For example:
Class MyTools
Public MyProperty
Public Sub Class_Initialize()
MyProperty = "foo"
End Sub
Public Sub SetMyProperty(str)
MyProperty = str
End Sub
End Class
In your global tools app, you would instantiate a copy of this class as
an object, and then share it via SharedObjects on launch (assuming it's
not already shared), like this:
If SharedObjects("com.myName.MyApp.MyTools", 0) Is Nothing Then
SharedObjects.Register "com.myName.MyApp.MyTools", New MyTools
End If
The namespace com.MyName.MyApp.MyTools is unique enough to keep from
clashing with any other shared objects.
Your class, now instantiated as an object, is shared in the Window-Eyes
SharedObjects object, which is available to any other app that cares to
access it. In fact, when your object is shared, Window-Eyes fires any
event indicating as much, so every app interested can immediately snatch
up a copy of your object for use. In addition, each app that does use
your shared object will get their own copy to avoid inter-app mingling.
In your main app, hook the SharedObjects OnStateChange event, and when
you see your object come through with a valid state, store it in a
global variable, like this:
Dim myToolsObj : Set myToolsObj = Nothing
Sub OnStateChange(objName, objState)
If objName = "com.MyName.MyApp.MyTools" Then
If objState Then
Set myToolsObj = SharedObjects(objName, 0)
End if
End If
End Sub
Now you can use the functions defined in your class, like this:
If Not myToolsObj Is Nothing Then
Speak myToolsObj.MyProperty
End If
That would give you back "foo."
If Not myToolsObj Is Nothing Then
myToolsObj.SetMyProperty("bar")
speak myToolsObj.MyProperty
End If
That would give you back "bar."
And so on, and so on. The Toolkit is the best place to look for example
of sharing objects, because it goes out of its way to ensure that the
objects are shared and released efficiently. And all of the GW Micro
apps take advantage of toolkit objects. In fact, any app on App Central
that provides automatic check for updates, hotkey management, error
reporting, etc., all rely on object that the toolkit has shared in the
global/public shared objects space.
Aaron
On 2/21/2012 12:39 PM, David Helkenn wrote:
Hello, Colleagues,
I am designing two related apps that are viewed as two different
scripts, but, they share common data elements (constants and arrays,
and even a couple of routines.) If I were doing this in a high level
programming language, I'd seriously consider making a class with the
two scripts instantiating objects of that class and letting the
properties, methods, and events go with each. The share information
would be available to each.
I could also use 'include' files or units. VBScript seems to have no
such facility for including simple data sets shared between scripts. I
had thought of simply combining the two scripts into the one .vbs
file, but that means complicating something that should be
straightforward.
So, am I forced to define VBScript objects? How is that done? Is the
one file solution required? I doubt it, but I'm not yet experienced
enough to know the alternatives.
Thanks for the help!
David
--
Aaron Smith
Web Development * App Development * Product Support Specialist
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
