Hi Jeff,
That is what I wanted to know since vbscript has no shared object itself.
Bruce
From: Jeff Bishop
Sent: Friday, March 04, 2011 9:11 PM
Subject: RE: Import Statement In VB
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
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 SpecialistGW
Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825260-489-3671 *
gwmicro.com To insure that you receive proper support, please include all
pastcorrespondence (where applicable), and any relevant informationpertinent to
your situation when submitting a problem report to the GWMicro Technical
Support Team.
