Bruce,
Which documentation were you refering to concerning shared objects? The GW Toolkit is nothing but a series of shared objects and is written in vbscript. The Winamp and SPLStudio scripts utilize shared objects as well as many other scripts. A shared object can be created from any language by using the object model of Window-Eyes. From: bT [mailto:[email protected]] Sent: Friday, March 04, 2011 6:00 PM To: [email protected] Subject: Re: Import Statement In VB Hi! When reading up on shared objects it is all based in visual Basic and not .vbs script. Now what has been done to allow the shared objects to include vbs scripts? Bruce From: Ron Parker <mailto:[email protected]> Sent: Monday, February 28, 2011 9:50 PM Subject: Re: Import Statement In VB The biggest difference between included objects and shared objects is that shared objects really are shared. You can make it so multiple scripts share the same object, and the same object's state. You can also use shared objects across languages, which might be useful if you need functionality that's not natively available from VBScript, but want to use VBScript for the majority of your code. (See, for example, how immed.vbs and immed.js work together to give you a JScript scratchpad.) Actually, this "include boilerplate code" functionality is itself a good candidate for a shared object. If there's not already something like it in the toolkit, Aaron's been asleep at the switch. (And it's an even better candidate for a new method for the Script object in some far-future version of Window-Eyes - I think we have access to your scripting environment that would let us inject the code directly into the interpreter, without you even having to call ExecuteGlobal. But don't hold me to that.) On 2/28/2011 8:04 PM, Chip Orange wrote: thanks Aaron. However, I don't think this answered my question: why couldn't you put the same code (except for the portions which dealt with being a shared object) of the toolkit into a file, which scripters could import. they could then create and use the same objects/classes just as if they had gotten them via the shared object mechanism right? and there is only one copy to be maintained, so while those points you made were all true, I don't see how they spoke to this comparison of the two ways of handling a library of routines/classes? thanks. Chip _____ From: Aaron Smith [mailto:[email protected]] Sent: Sunday, February 27, 2011 10:40 PM To: [email protected] Subject: Re: Import Statement In VB SharedObjects aren't segments of code. Instead, they're instantiated classes and/or functions. Their source don't exist inside the code of a running script (unless they're written to do so -- keep reading). SharedObjects are external objects or functions that can be referenced just like any COM object. One advantage of using a shared object is that you don't have to maintain or embed the code. Take, for example, the Toolkit's Env method that expands environment variables. In a single line of code you could do: Dim weDir : weDir = SharedObjects("com.GWMicro.GWToolkit.Env")("%wineyes%") and weDir would contain a string, something akin to C:\Program Files(x86)\GW Micro\Window-Eyes. The Env method isn't extensive, mind you. It's only 11 lines of code. But compare 11 lines that the author of that object must maintain with 1 line that the object user has to maintain. That being said, Execute and ExecuteGlobal are very useful. The Toolkit's error reporting object actually combines both of these features: it's a shared object that executes code within the calling script. That way, the errors are relative to the calling script, and not the toolkit. Aaron On 2/27/2011 10:00 PM, Chip Orange wrote: thanks Bruce. Doug or Aaron, I'm wondering, how would importing "library" code using this method compare to the current use of shared objects? wouldn't this allow WE to completely do without shared objects if this were used instead, and GW published the toolkit as text meant to be imported this way? Except for the GPS shared object I created to allow multiple scripts to share a single resource, a very odd use of shared objects I realize, I'm not sure what advantages shared objects have over this "include" statement? thanks for any thoughts and explanations. Chip _____ From: bT [mailto:[email protected]] Sent: Sunday, February 27, 2011 9:49 PM To: [email protected] Subject: Import Statement In VB ' THIS IS JUST A COMMENT SECTION WHERE THE ' CHARACTER OR REM CAN BE USED FOR COMMENTS. ' THE VARIABLE NAMES I USE ARE THE STANDARD NAMES USED IN GOOD PROGRAMMING PRACTICE. ' SO IF IT IS A STRING THE USE STR AT THE BEGINNING OR AN OBJECT USE OBJ. ' BUT I DID NOT USE STR FOR THE FILE NAME JUST TO MAKE IT EASIER TO READ. ' BELOW IS A SUBROUTINE WHICH WILL SET UP AN IMPORT OF LIST OF CLASSES AND PROCEDURES OF ANY KIND. ' ALL YOU ENTER IS THE NAME OF THE FILE YOU WISH TO IMPORT AS SHOWN AT THE BOTTOM. ' JUST ADD THIS SUBROUTINE TO ANY VBS PROGRAM AND CALL IT WITH A FILENAME AS THE PARAMETER OF THE IMPORT SUBROUTINE. ' ALL CLASSES, FUNCTIONS AND PROCEDURES IN THIS FILE ARE THEN ASSIGNED GLOBAL AT THE END OF THE SUBROUTINE WHEN IT IS CALLED! Sub Import( FileName) ' A PROCEDURE TO LOAD ANY LIBRARY OF FUNCTIONS, PROCEDURES, OR VARIABLES AND CONSTANTS. ' FIRST DECLARE THE VARIABLES YOU ARE GOING TO USE SO VB KNOWS THEM. Dim strCode, objFS, objFile, WshShell ' CREATE AN INSTANCE OF THE SHELL TO THE COMAND LINE FILE SYSTEM. ' THIS WILL ALLOW YOU TO USE THE ENVIRONMENT EXPAND METHOD WHEN BUILDING THE PATH FILE NAME. ' NOTE ALL OBJECT NAMES MUST HAVE A SET COMMAND BEFORE IT'S NAME. ' ALSO NOTE: I USE THE WORD INSTANCE TO REFER TO THE OBJECT CREATED, SINCEIT IS ACTUALLY JUST ONE INSTANCE OF THAT OBJECT. Set WshShell = WScript.CreateObject("WScript.Shell") ' THEN CREATE AN INSTANCE OF THE FILE SYSTEM SO YOU CAN OPEN A FILE FOR READING. Set objFS = CreateObject( "Scripting.FileSystemObject") ' THEN EXPAND ANY ENVIRONMENT VARIABLES YOU MAY HAVE IN YOUR FILE NAME, SUCH AS %WINDIR%. ' THIS ALLOWS YOU TO FIND THE FULL PATH LIKE YOUR WINDOWS FOLDER PATH. FileName = WshShell.ExpandEnvironmentStrings( FileName) ' NOW IF YOU ONLY HAVE YOUR FILE NAME THEN BUILD ONTO IT THE PATH TO THAT FILE. FileName = objFS.GetAbsolutePathName( FileName) ' NOW OPEN THE FILE WHICH HAS YOUR LIBRARY OF FUNCTIONS AND PROCEDURES YOU WANT TO INCLUDE. Set objFile = objFS.OpenTextFile( FileName) ' NOW READ THE ENTIRE FILE USING THE READALL METHOD. strCode = objFile.ReadAll ' THEN CLOSE THE FILE SO IT DOES NOT MESS UP YOUR SYSTEM OR WINDOWS. objFile.Close ' NOW THE MAGIC PART, EXECUTE THE STRING YOU READ IN SO ALL FUNCTIONS AND PROCEDURES ARE NOW A GLOBAL PART OF YOUR PROGRAM. ExecuteGlobal strCode ' LAST BUT NOT LEAST, SHUT DOWN, ERASE AL OBJECTS YOU CREATED FROM MEMORY. Set WshShell = Nothing Set objFS = Nothing Set objfile = Nothing End Sub ' NOW LOAD IN YOUR LIBRARY YOU WISH TO INSTALL USING THE ABOVE PROCEDURE! ' I AM LOADING A CLASS I MADE FOR SAPI 4 AND SAPI 5 VOICES. ' BY IMPORTING THIS CLASS I CAN NOW USE IT TO MAKE SAPI VOICE OBJECTS. Import "Sapi45Class.vbs" ' I COMMENTED THIS SO A PERSON JUST LEARNING SCRIPT WILL UNDERSTAND WHAT I DID. -- 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.
