Bierman on COM

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.

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.