Purpose |
Communicate with a COM object through the dispatch interface. | ||||||||||
Syntax |
OBJECT GET interface.member[.member.]
[([[paramname =] param1
[, ...]])] TO ResultVar | ||||||||||
Remarks |
There are five general forms of the OBJECT statement which are used to communicate through a Dispatch interface to an object.
All parameters, return values, and assignment values
must be in the form of COM-compatible
variables. Literals
and expressions are not allowed. COM-compatible
variables include BYTE, WORD,
DWORD, INTEGER,
LONG, QUAD,
SINGLE, DOUBLE,
CURRENCY,
Dispatch OBJECT Method calls may be bound at run-time using late binding, which requires no declaration of Properties and Methods. However, for this very reason, the validity of these references can not be verified by PowerBASIC at the time the program is compiled. The OBJECT statement can use both positional and named parameters, but you should keep in mind that not all COM Dispatch Servers support named parameters. Positional parameters are universally supported. A positional parameter is simply a variable containing an appropriate value. It is identified by its position in the parameter list, just as in a traditional SUB or FUNCTION. A named parameter consists of a parameter identifier (a name), an equal (=) sign, and a variable containing an appropriate value. Positional parameters must precede any and all named parameters, but named parameters may be specified in any sequence. Each time you call a Method or Property using the OBJECT statement, a status code is returned in a hidden parameter to indicate the success or failure of the operation. You can retrieve information about this status code with the OBJRESULT function, and also by using the IDISPINFO Dispatch Information Object. If the failure was severe, then a PowerBASIC error 99 (Object Error) is also generated and the ERR system variable is set. You can find more information about these items by referring to OBJRESULT, IDISPINFO, and ERR. This information can be very useful for both debugging and handling run-time errors. | ||||||||||
Restrictions |
All parameters, return values, and assignment values must be in the form of COM-compatible variables. Use of the wrong member mode (GET/LET/SET/CALL/RAISEEVENT) can sometimes result in unexpected and fatal run-time errors. So, it's usually prudent to test the result code in OBJRESULT after every OBJECT statement. | ||||||||||
See also |
ACODE$, DIM, CLASS, CLSID$, EVENT SOURCE, IDISPINFO, GUID$, GUIDTXT$, ID Binding, INTERFACE (Direct), INTERFACE (IDBind), ISINTERFACE, ISNOTHING, ISOBJECT, Just what is COM?, Late Binding, LET (with Objects), METHOD, OBJACTIVE, OBJPTR, OBJRESULT, PROGID$, PROPERTY, UCODE$, What is an object, anyway?, What is DISPATCH? | ||||||||||
Example |
' Assumes Interface definitions have been |