Dave,
You get to the toolkit's help by going to the Window-Eyes Apps menu,
going to the GW Toolkit option and opening it up. The first option in
that pulldown is help, so select that. A dialog comes up with the
"Launch Help" button selected by default. Hit enter and you are in the
Windows Help with the Toolkit's objects listed in the treeview. The
format is just like the Window-Eyes "app developer reference" manual.
Doug
On 2/21/2012 2:47 PM, David Helkenn wrote:
Thank you very much, Aaron! Now, if I could find the documentation on
GWToolkit... I find the GW Micro Object model info in the
documentation option of the WE control panel's help menu, but I don't
find GWToolkit on AppCentral. Of course, I find the toolkit script
info, but it does not seem like the right document. Am I missing
something?
Dave
At 10:08 AM 2/21/2012, you wrote:
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.
