Can anyone advise me on how to unsubscribe from this list please?
-----Original Message----- From: David Helkenn [mailto:[email protected]] Sent: 22 February 2012 00:46 To: [email protected] Subject: RE: Shared Data Implementation I would use Ada, my favorite, but the requirement to have its own support engine for the interpreter is a major deterent, so I'll stay with VBS which is interesting in its own way. Dave At 01:50 PM 2/21/2012, you wrote: >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. > >
