Now since you mentioned higher-level languages, why not use one that
you like better? C#, perhaps?
-----Original Message-----
From: Doug Geoffray [mailto:[email protected]]
Sent: Tuesday, February 21, 2012 3:17 PM
To: [email protected]
Subject: Re: Shared Data Implementation
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.
>
