Using Objects with Object REXX
Object REXX is the only scripting language I discuss in this book that isn't free. However, this is more than made up for by the sophistication of the Object REXX full development edition and its powerful debugger. Because you can install the free runtime version of Object REXX on all your organization's computers and only need to buy the full REXX program for a limited number of development computers, if you're familiar with REXX already and you factor in the time you can save in debugging, it's actually a very cost-effective scripting solution.
Object REXX supports its own brand of built-in objects and lets you create objects within REXX for use by scripts. It uses the same syntax for COM/OLE/ActiveX objects. The syntax for REXX object references is
objectname~method
An instance of a standard built-in or user-defined REXX object is created with a statement like this:
rexxobject = .objectname~new
However, you must create instances of Windows COM/ActiveX objects using a special COM object "factory" class named OLEObject. Because OLEObject is not a built-in class, to use it in your REXX script you must add the following requires statement at the end of your script file:
::requires "OREXXOLE.CLS"
There are three ways to create OLE objects. The most common way is with the statement
rexxobject = .OLEObject~new("Server.Object")
This creates an instance of a Windows object of type Server.Object, and it returns the new object.
To create an ActiveX object given a monikerthe "nickname" of the object or the name of a document file whose file type is associated with the application serveruse the GETOBJECT method:
Rexxobject = .OLEObject~GETOBJECT(moniker [, subclass])
Finally, to let the object create REXX events, you can use this version of the New method:
rexxobject = .OLEObject~new("Server.Object", "WITHEVENTS")
You should note, however, that the use of events is beyond the scope of this book.
In addition to any methods or properties defined by the ActiveX object itself, REXX adds several additional methods. These extra methods help integrate the Windows and REXX universes. The extra methods are listed in Reference List 3.2.
Reference List 3.2 Extra Methods added to COM Objects by Object REXX.
GETCONSTANT (name)
Lets you access any predefined constant values that are associated with the object. Whereas VBScript simply makes an object's defined constants available automatically once an object is created, in Object REXX you must explicitly look them up. For example, the Windows Speech object uses a constant value named ttxtst_READING. To get the value of this constant in REXX, you can use the statement flagval = talk.GetConstant("vtxtst_READING").
GETKNOWNEVENTS
Returns a stem (a REXX collection object) describing the events that the OLE object can create. See the Object REXX documentation for details.
GETKNOWNMETHODS
Returns a stem with information on all the methods provided by the OLE object.
GETOUTPARAMETERS
Returns a REXX array consisting of any "output" parameters set by the OLE object during the last reference to one of its methods.
Here is an Object REXX script that demonstrates the use of GetConstant. It uses the Windows Speech object to greet you:
talk = .OLEObject~new("Speech.VoiceText") flags = talk~GetConstant("vtxtst_READING") -- define type of speech talk~register('',"Object REXX Test App") talk~enabled = .true talk~speed = 280 talk~speak("Hello, this is REXX speaking.", flags) do while talk~isspeaking call SysSleep 1 end exit ::requires "orexxole.cls"
NOTE
Object REXX does not support DCOM and does not support the creation of server objects that can be called from other languages and environments.
Creating Object REXX Files
The Object REXX installer sets up two file associations: .rex (REXXScript) for files meant be run by REXX directly, and .rxs (ObjectRexxScriptFile) for files meant to be run with cscript or wscript.
Which file extension should you use? If you want to use the REXX development environment and debugger, you should create .rex files. This is probably the most efficient way to go. If you want to use the WScript built-in object that I discuss in this chapter and elsewhere, you'll need to run your scripts with wscript/cscript, because only the WSH environment creates this predefined object and it can't be created with the OLEObject method. In this case, you must forgo the debugger. To be honest, I think the debugger is more valuable than the WScript object.
Working with Collections
Many Windows Scripting objects return groups of information called collections, as I discussed earlier in the chapter. Object REXX has the do...over statement to loop through the items of a collection.
Pattern
The structure do obj over collectionobject statements using object obj ... endexecutes the enclosed statements once for each object in the collection. Variable obj refers to each one of the objects in turn; you can use any variable name in place of obj.
For example, the following script lists the files in the root folder of your C: drive:
fso = .OLEObject~new("Scripting.FileSystemObject") files = fso~GetFolder("C:\")~Files Say "There are" files~count "files" do file over files say file~name end ::requires "orexxole.cls"
Now that we've discussed the specifics of each WSH-compatible language, let's look at the WScript object that is provided to all Windows Script Host programs.