Bierman on COM
Bob Bierman, bierman@scripting.com, the guy who's working on the COM interface in Frontier 5, writes:Bierman on COM
In my rush to get this out I forgot to describe the actual interface.
Frontier's COM server model is based on the IDispatch interface. There is no type library associated with Frontier (which is why you can not "browse" the object model). This is really because of the infinite number of methods you can devise with the interface.
Frontier supports the Invoke and GetIDsOfNames methods of the IDispatch interface. The IDs returned from GetIDsOfNames are only valid while that object is in existence, since we just dynamically build a name list at run time. The ID is then used in the Invoke method which retrieves the name from the name list created in GetIDsOfNames to build the actual script name.
Frontier supports two other methods within this interface. These are FrontierExecute and GetObject. FrontierExecute is only there to provide a parallel to the DLL DoScript interface. FrontierExecute takes two parameters, an input string and a result string.
GetObject is a key method in the Frontier server model though it is not absolutely necessary. GetObject takes a single input parameter which is a string (BSTR). The string is the "path" to the script in Frontier you wish to execute. So in the sample the script basicSample is in the samples table (under user.com which is the default base path for all scripts executed by the COM server in Frontier). So we pass the string "samples" to GetObject. GetObject then returns in the second parameter (an out retval parameter) a new instance of the Frontier IDispatch interface object that has the path (as specified in the first parameter) as it's default base path.
The GetObject method is necessary since Frontier uses the dot '.' notation for its addresses you could not call "fi.samples.basicSample ("Hello")" since basic would interpret samples as it's own script. Also Frontier does not currently support the Evaluate dispID so you can not use the [samples.basicSample] notation.
GetObject is not necessary from C or C++ where you call GetIDsOfNames your self. There you could specify "samples.basicSample" as the name you want an ID for, this means you only need the one instance of the Frontier IDispatch interface around.
For the true COM geeks this is how the IDL looks for Frontier:
// Interface IFrontier [ object, uuid(8806B470-BEC8-11d1-B2BA-006008AF0E0E), helpstring("Frontier Interface"), pointer_default(unique), oleautomation ] interface IFrontier : IDispatch { import "oaidl.idl" ; HRESULT FrontierExecute([in] BSTR szIn, [out, retval] BSTR * szOut); HRESULT GetObject([in] BSTR path, [out, retval] IDispatch ** newobj); } ;Now, for what you can pass back and forth and what the scripts in Frontier can look like. The script in Frontier can look like any normal script with any number of parameters. Say you wanted to multiply three numbers, your script would look something like this:
on mult (a, b, c) return (a * b * c)The call from basic could look something like this:
answer = fi2.mult (4.6, 5, 3.141592)
There currently is a limit as to what can be passed back and forth. This is mainly dictated by the type support by OLE Automation and does not include an arbitrary block of memory. Note: Since Frontier runs in a different process than the application calling Frontier, all the memory has to be copied to the Frontier process and then back to the calling process so you lose efficiency by sending to large a block back and forth. The current version also does not support arrays (SAFEARRAY) structure, but this is in the works.
|
This page was last built on 4/3/98; 12:24:14 PM by David Winer. dave@scripting.com |