Hi!
Yes this has some advantages, but my import procedure does give some
flexibility for those who wish to make there own objects. Nothing is ever
perfect, but the routine comes in handy outside of the WE environment, one
reason why I decided to post it.
I supper commented it, and that is just an easy fix by deleting it.
So have fun for it gives more flexibility for script writers.
Bruce
----- Original Message -----
From: Aaron Smith
Sent: Sunday, February 27, 2011 10:40 PM
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.
