Fire as an OLE Server
Fire as an OLE Server Fire acts as an OLE server for the FireService Object which provides third party OLE client applications access to Fire functionality and embedded windows.
The Fire Service Object is an OLE object that exports Fire functionality to OLE client applications. It also enables Fire windows to be embedded within third party OLE client applications. The object is served by the executables fire.exe and FireService.dll.
When a FireService object (known for historical reasons as the Formida.FireService object) is instantiated, it is served by a Fire session. The Fire session will be named or unnamed according to the value of the Service Object's AppSession property. When all references to an instance of the Service Object are released, the object will be deleted.
If AppSession is defined but has an empty string value, a new unnamed Fire Session will be opened to serve the object. When the object is released, the Fire session which serves it gets terminated.
If AppSession is a valid non-empty stringl, the object will be served by an existing Fire session having the specified session name. If Appsession is not defined, i.e. null, a default session name is used, either ExistingFireSession or the value of the environment variable DEFAULTFIRESESSION, if defined. If the named Fire session does not exist, a new named session will be opened. A Fire session that was opened to serve one or more such Formida.FireService objects will be closed automatically when it no longer serves any Service Objects. This behaviour can be overriden, to permit a FireSession to remain open.
The Fire Service Object exports the methods listed below.
On success a method returns S_OK. Error values indicate when arguments are of incorrect type, or when an expression cannot be evaluated, for example Evaluate.
CreateNewObject:
Creates a new instance of the Service object. The new object will be served by the same Fire session that serves the object on which this method is invoked.
Syntax: HRESULT CreateNewObject(IFireService**)
Execute:
Executes the given Fire command string. A return to the client is made when the command has completed execution.
Syntax: HRESULT Execute(string command)
Note that the command is executed within its own command frame; for example, sending the command string s = 'abc' to the Service Object is equivalent to sending the command {string s = ‘abc’}, hence the declaration only has scope within the single command line.
This is essentially the same as Execute, but a return to the client is made immediately without waiting for the command string to execute.
Syntax: HRESULT ExecuteAsync(string command)
If a previous ExecuteAsync is still executing, this call may be executed in-line within the previous one. This may have undesired effects so care should be taken. A test can be made to determine whether Fire is currently processing another ExecuteAysnc by calling
HRESULT Evaluate("async_busy", VARIANT* result)
GetId:
Returns the ID number of the Service Object instance. This is used in window embedding commands such as
embed <tag_name>,-ole=<id>Syntax: HRESULT GetId(long**)
Evaluates the given Fire expression and returns the result of the expression. This expression can be a simple Fire identifier or something more complex, for example, a function.
Syntax: HRESULT GetValue(string expression, VARIANT* result)
Syntax: HRESULT Evaluate(string expression, VARIANT* result)
SetValue:
Assigns a value to a Fire identifier. Note that the assignment is executed within its own command frame. A return to the client is made only when the assignment completed.
Syntax: HRESULT SetValue(string expression, VARIANT value)
SetValueAsync:
This is essentially the same as SetValue, but a return to the client is made immediately without waiting for the completion of the assignment. See ExecuteAsync for synchronization issues.
Syntax: HRESULT SetValueAsync(string expression, VARIANT value)
The Fire Service Object exports the properties listed below. All properties support get and set methods.
Properties can be changed at runtime by:
using the appropriate client syntax for <object>.<property> assignment, or
using the DoVerb command to show the property page.
Properties can be changed at design time by:
using the Properties window in the client, or
using the custom property page in the client container.
AppSession:
This property specifies the name of the Fire session in which the Service Object runs. Service Objects having the same AppSession name will run in the same named Fire session.
If AppSession is an empty string, then the Service Object will run in an unnamed Fire session, which will be created.
If AppSession is a valid and non-empty string , then the Service Object will run in the named Fire session. If Appsession is not defined, i.e. null, a default value is assumed, either ExistingFireSession or the value of the environment variable DEFAULTFIRESESSION if defined. If the named session already exists then the Service Object will attach to it, otherwise the named session will be created. When such a named Fire session no longer serves any Service Objects, i.e. when they have been deleted and released, the Fire session will get terminated. This behaviour can be suppressed by suffixing the AppSession value with "_retain", in which case the Fire session will remain open and available for re-use by another Service Object.
If the AppSession property is changed, the Service Object's reference to the old session is released, and if the reference count reaches zero, the session is closed.
Syntax: BSTR AppSession
AppStart:
This property specifies the URL, or file specification, of a Fire application to be started when the Service Object is instantiated. Setting this property allows the Service Object to use Fire's WAM application start-up mechanism. The default value of AppStart is null.
If AppStart is null, Fire takes no action. This is the same behavior as the Fire 3.0 Service Object.
If the AppStart property is not null, Fire will attempt to start the specified application.
Syntax: BSTR AppStart
AppView:
This property specifies the name used by Fire's WAM application start-up mechanism to refer to the embedded window. It defines the window embedding tag, used in the Fire embed command. It is only used if AppStart has been set to an application.
Syntax: BSTR AppView
ReleaseKernelOnClose:
This property is used to indicate that the kernel should be released when the Service Object is deactivated, rather than when it is destroyed. Required for some client containers (for example, Developer 2000) which fail to release OLE objects correctly.
Syntax: BSTR ReleaseKernelOnClose
The Fire Service Object exports a single event to the OLE client.
FireServiceEvent:
This event has one string parameter, the meaning of which is determined by the developer.
Syntax: VOID FireServiceEvent(string event_string)
The event is raised by the Fire command:
raise_event <instance_id_number>,<quoted_event_string>and can be received by the OLE client. (See appropriate section below for details).
A –syn switch may be added to the raise_event command. This will force Fire to wait for acknowledgement from the OLE client before continuing. This acknowledgment will be sent when the OLE client has received and processed the event. This is in contrast to the default behavior of raise_event (without –syn) which allows Fire to continue processing without waiting for such an acknowledgment.
Fire windows can be created and embedded in a client application. An embedded window is served by a particular instance of the Fire Service Object, identified by its instance Id.
The status of the embedded window is indicated in a client container by the window's background colour:
White
Window is Active
Blue
Window is UIActive (i.e. menu/toolbar is merged in the client)
Yellow
Window is Inactive
When the Service Object is embedded in a container window, it displays the values of its static properties as follows:
Formida Service Object Session <AppSession> (OR unnamed Session)
Application = <AppStart>
View Name = <AppView>
Instance id = <Instance Id>
Within Fire application code, to identify an embedded window by name use the commands embed and unembed. For example
# Create an embedded window tag for Service Object instance Id 5 embed "test", –ole = 5 # Detach an embedded window unembed "test"
To indicate that a Fire window creation command (e.g. wgraphic, walpha, etc.) should use an embedded window, specify the window tag with the –emb switch. For example:
# Create a window and associate with embedded window “test” wgraphic –emb = “test”
The Fire Service Object supports Fire's WAM application start-up mechanism. To automatically start a Fire application in a Fire Service Object window:
Specify the name of the Fire session using the AppSession property.
Specify the URL (or filespec) of the application using the AppStart property.
Specify the name used by Fire for the embedded window using the AppView property.
Fire Session Moniker:
For the Service Object running in a named Fire session, the AppSession property is used to construct a file moniker, MXMONIKER\<AppSession>.lll, which is bound and registered to a named Fire Service object.
The MXMONIKER environment variable, which by default is set to the value of MXTEMPDIR, determines the directory used for the Fire session file <AppSession>.lll.
MXMONIKER would normally be changed only in the following cases:
the user requires the Fire session file directory to be something other than MXTEMPDIR, or
multiple instances of a client application need to attach to separate Fire sessions even though the Service Object in the client application has a specified AppSession name.
No changes are required to the Fire 3.0 Existing Session service object. AppSession is set to its default value of "ExistingFireSession".
The Fire 3.0 New Session service object is no longer supported. Any New Session service objects should be replaced with the Fire 5 Service Object and AppSession should be cleared, since it is initially set to its default value.
Visual Basic 5.0 can use the Fire Service Object as follows:
In an ActiveX Control – the Service Object as an OCX
In an OLE Container – the Service Object as an in-place activated object
As an OLE object – the Service Object as an automation (non-visual) object
Visual Basic 3.0 can use the Fire Service Object as follows:
In an OLE Container – the Service Object as an externally activated object
As an OLE object – the Service Object as an automation (non-visual) object
Adding the Service Object to the Visual Basic toolbox
To use the Fire Service Object as an ActivateX control it must be selected from the Visual Basic toolbox and added to the form at design time. Add the Fire Service control to the Visual Basic toolbox as follows:
1. Select Project --> Components --> Insertable Objects
2. Check the box against the Fire Service Object components to be added.
An icon will be added to the toolbox for each of the selected components.
Using the ActiveX Service Object's methods
To use the ActiveX Service Object's methods use the following syntax:
<result_var> = <activex_control_name>.object.<method_name> <parameter(s)>
Example:
' Get the Service Object instance id Dim id as long id = FireService1.object.GetId
Adding code to the ActiveX Service Object's event
The ActiveX Service Object's event can be found merged with the standard ActiveX control events where code can be added as for any other event.
Example:
Sub FireService1_FireServiceEvent(ByVal event_string As String)
' Put event code here...
MsgBox event_string
End Sub
Embedding the Service Object in an OLE control
To use the Fire Service Object as an in-place activation object it must be embedded in an OLE control. It can be activated using the OLE control’s default verb, and its automation methods (but not its event) can be accessed.
To embed the Fire Service Object in an OLE control at design time:
1. Invoke the Insert Object dialog.
2. Select "Formida FireService Control" from the list of insertable objects.
To embed the Fire Service Object in an OLE control at runtime, use the following as an example:
' Create embedded object in OLE container ole1.CreateEmbed "","Formida.FireService" ' Activate the embedded object ole1.DoVerb bOLEPrimary
Using the embedded Service Object's methods
To use the embedded Service Object's methods, use the following syntax:
<result_var> = <ole_container_name>.object.<method_name> <parameter(s)>
Example::
' Get the Service Object instance id Dim id as long id = ole1.object.GetId ' Evaluate a string expression Dim s As String s = ole1.object.Evaluate( <string expression> ) MsgBox "Expression evaluated to " + s ' Execute a Fire command ole1.object.Execute "dir"
Creating a Fire window for embedding
To create a Fire window for embedding:
1.Obtain the Service Object instance ID.
2. Define an embedding tag associated with the instance.
3. Create the window.
Example:
' Get the Service Object instance id
Dim id as long
id = ole1.object.GetId
' Define and create an embedded graphic window
ole1.object.Execute("embed 'test', –ole = " + id)
ole1.object.Execute("wgraphic –emb = 'test'")
To use the Fire Service Object as an automation object, declare an object variable, then create an instance of the service object and assign a reference to it.
Example:
' Declare an object variable
Dim fsobject As Object
' Create service object and assign reference to it
Set fsobject = CreateObject("Formida.FireService")
Using early binding
To use early binding, add the Formida Service Type Library to the project as follows:
1. Select the Project --> References menu item.
2. Add the type library.
3. Declare a Fire Service object variable.
4. Create an instance of the service object and assign a reference to it.
Example:
' Declare a FireService variable Dim fsobject As FireService ' Create service object and assign reference to it Set fsobject = New FireService
Using the Service Object's methods
To use the Service Object's methods, use the following syntax:
<result_var> = <object_var>.<method_name> <parameter(s)>
Example:
' Execute a command to create a graphic window
fsobject.Execute "window ~global.w = wgraphic"
' Get the Service Object instance id
Dim id As Long
id = fsobject.GetID()
' Evaluate an integer expression
Dim n As Integer
n = fsobject.Evaluate("err")
' Evaluate a string expression
Dim s As String
s = fsobject.Evaluate("units")
To create another instance of the Service Object in the same session use the CreateNewObject method.
Example:
' Create another instance of the Service Object Dim fsother As Object Set fsother = fsobject.CreateNewObject fsother.Execute "dir" Set fsother = Nothing
Deleting (releasing) the Service Object
To delete (release) the Service Object:
Set fsobject = Nothing
Receiving the Service Object event
In Visual Basic 5.0 the Service Object event can be received by an object declared with the Withevents keyword.
Note: Dim Withevents can only be used in a Class module.
Example
' Declare a FireService variable Dim Withevents fso As FireService ' Create service object and assign a reference to it Set fso = New FireService
The Service Object event code is entered as for any other event.
Example
Private Sub fso_FireServiceEvent(ByVal event_string As String)
' Show passed parameter
MsgBox "Event string = " + event_string
...
End Sub
The Visual Basic syntax for the Service Object's methods, properties and events is given below.
Service Object Methods:
Sub CreateNewObject(ppObject As IFireService)
Function Evaluate(expression As String) As Variant
Sub Execute(bstrCommand As String) (See note 1)
Sub ExecuteAsync(bstrCommand As String)
Function GetId () As Long
Function GetValue(expression As String) As Variant
Sub Save(bstrFileName As String, fRemember As Long) (See note 3)
Sub SetValue(variable As String, value As Variant)
Sub SetValueAsync(variable As String, value)
Service Object Properties:
Property AppSession As String
Property AppStart As String
Property AppView As String
Property ReleasekernelOnClose As Long (See note 2)
Service Object Events:
Event FireServiceEvent (event_string As String) (See note 2)
Notes:
1. The Execute method must be enclosed in square brackets in VB3. Square brackets are not required in VB5 which interprets them as an array of values for the object then sends error –5 to Fire.
2. Not available for the FireAutomation object.
3. Only available for the FireAutomation object.
Developer 2000 can use the Fire Service Object as an ActiveX control in a Developer 2000 form.
To use the Fire Service Object as an OCX:
Create a canvas.
Select OCX from the toolbar.
Draw the ActiveX control on the canvas.
Right-click on the OCX control and choose Insert Object from the pop-up menu.
Select Formida.FireService.
The Fire Service Object will be inserted and a Fire session will be started.
Note: One Fire session will serve both design mode and run mode.
In order to use the Service Object's methods and events in Developer 2000, the Service Object's packages must be imported. To do this:
From the Program menu, select OLE Importer and choose Formida.FireService from the list of objects.
Highlight IFireService or IFireServiceEx Method packages (see Syntax).
Highlight the _IFireServiceEvent Event package.
Click OK.
The Service Object's interfaces will be imported and can be viewed in the Program Units item for the current module.
When a Developer 2000 application uses an embedded Fire window, the Fire application which embeds the window needs to know the instance id of the FireService ActiveX control. To start a Fire application automatically when a Developer 2000 form is created place the required code in a when-new-form-instance trigger which is called after the form has been created, to make the window id available.
Example:
Declare
Inst_id number;
Msg varchar2(500);
Begin
-- Get the instance id of the Service Object ActiveX control
Inst_id := Formida_IFireService.GetId(:item('BLOCK1.OCX1').Interface);
-- Set the instance id in Fire as the variable ~global.ole_id
-- (or pass the instance id to the application as a parameter)
Msg := 'numeric ~global.ole_id =' || Inst_id;
Formida_IFireService.Execute(:item('BLOCK1.OCX1').interface, Msg);
-- Start the Fire application
Msg := 'path c:/projects/dev2000/app/fire; exec start';
Formida_IFireService.Execute(:item('BLOCK1.OCX1').Interface, Msg);
End;
If you have more than one canvas, and the canvas which contains the ActiveX control is not displayed when the application starts, Developer 2000 must be made to instantiate the control, for example:
-- ActiveX control in BLOCK1
go_block(BLOCK1);<
If not form_success then
raise form_trigger_failure;
End if;
To use the Service Object methods place the required code in the appropriate trigger.
Example:
Declare
Msg varchar2(100);
Eval_Res oleVar;
Begin
-- Set up an expression to be evaluated
Msg := '~app.numeric_function(123)';
Eval_res :=
Formida_IFireService.Evaluate(:item('BLOCK1.OCX1').Interface, Msg);
-- Display result in a text field
:text_res := var_to_char( Eval_res );
End;
To handle the Service Object event in Developer 2000, the event code may be placed in one of the following:
In the ON-DISPATCH-EVENT trigger of the ActiveX control.
Note: The event_string parameter is not available in this trigger.
In the Formida_IFireService_Events package body. Enter the required event handling code and compile the package.
Note: All event procedures are restricted i.e. a go_item cannot be called from within the procedure code. See also Developer 2000 help topic: "Responding to ActiveX control events".
To use the Service Object properties place the required code, using the IFireServiceEx interface, in the appropriate trigger.>
Example.
Declare
Session_name varchar2(100);
Begin
-- Get Fire session name
Session_name :=
Formida_IFireServiceEx.AppSession(:item('BLOCK1.OCX1').Interface);
-- Display session name in a text field
:text_session := Session_name;
End;
Fire should release any Service Objects created by a Developer 2000 application when the application terminates. However, a Developer 2000 problem prevents this from occurring (see Technical Notes). To force Fire to release the Service Objects when the application terminates, the ReleaseKernelOnClose property of the object should be set
Example.
Formida_IFireService.ReleaseKernelOnClose(:item('BLOCK1.OCX1').Interface,
1);
Note: This Developer 2000 issue may have been solved by the time of this publication.
The Developer 2000 package spec for the Service Object's methods and events is given below.
Service Object Methods:
PACKAGE Formida_IFireServiceEx IS
PROCEDURE QueryInterface(interface OleObj, riid OleVar, ppvObj IN OUT
FUNCTION AddRef(interface OleObj) RETURN NUMBER;
FUNCTION ole_Release(interface OleObj) RETURN NUMBER;
PROCEDURE GetTypeInfoCount(interface OleObj, pctinfo IN OUT NUMBER);
PROCEDURE GetTypeInfo(interface OleObj, itinfo NUMBER, lcid NUMBER,
pptinfo IN OUT OleVar);
PROCEDURE GetIDsOfNames(interface OleObj, riid OleVar, rgszNames OleVar,
cNames NUMBER, lcid NUMBER, rgdispid IN OUT NUMBER);
PROCEDURE Invoke(interface OleObj, dispidMember NUMBER, riid OleVar,
lcid NUMBER, wFlags NUMBER, pdispparams OleVar, pvarResult IN OUT OleVar,
pexcepinfo IN OUT OleVar, puArgErr IN OUT NUMBER);
/* Execute Fire command */
PROCEDURE Execute(interface OleObj, bstrCommand VARCHAR2);
/* Execute Fire command (asynchronously) */
PROCEDURE ExecuteAsync(interface OleObj, bstrCommand VARCHAR2);
/* Set Fire variable */
PROCEDURE SetValue(interface OleObj, variable VARCHAR2, value OleVar);
/* Set Fire variable (asynchronously) */
PROCEDURE SetValueAsync(interface OleObj, variable VARCHAR2, value OleVar);
/* Evaluate Fire expression */
FUNCTION GetValue(interface OleObj, expression VARCHAR2) RETURN OleVar;
/* Evaluate Fire expression */
FUNCTION Evaluate(interface OleObj, expression VARCHAR2) RETURN OleVar;
/* Get instance ID */
FUNCTION GetId(interface OleObj) RETURN NUMBER;
/* ReleaseKernelOnClose - Release Kernel on VERB Close or on EXIT */
FUNCTION ReleaseKernelOnClose(interface OleObj) RETURN NUMBER;
/* ReleaseKernelOnClose - Release Kernel on VERB Close or on EXIT */
PROCEDURE ReleaseKernelOnClose(interface OleObj, ReleaseKernelOnClose NUMBER);
/* Create new service object in current session */
PROCEDURE CreateNewObject(interface OleObj, ppObject IN OUT OleVar);
/* Note: The following methods are only available in the IFireServiceEx interface. */
/* Fire Session Name */
FUNCTION AppSession(interface OleObj) RETURN VARCHAR2;
/* Fire Session Name */
PROCEDURE AppSession(interface OleObj, AppSession VARCHAR2);
/* Fire View Name */
FUNCTION AppView(interface OleObj) RETURN VARCHAR2;
/* Fire View Name */
PROCEDURE AppView(interface OleObj, AppView VARCHAR2);
/* Fire Application Name */
FUNCTION AppStart(interface OleObj) RETURN VARCHAR2;
/* Fire Application Name */
PROCEDURE AppStart(interface OleObj, AppStart VARCHAR2);
/* Fire Instance Name */
FUNCTION FireInstanceName(interface OleObj) RETURN VARCHAR2;
END;
Service Object Events:
PACKAGE Formida_IFireService_EVENTS IS
/* FireServiceEvent */
PROCEDURE EVENT100(interface OleObj, event_string IN OUT VARCHAR2);
END;
Developer 2000 Release 2.0 seemed to have difficulty in correctly releasing OCX's. Consequently, when the Developer 2000 application terminated, the Fire session was still serving the Service objects. This can be fixed for objects instantiated at run time by setting the object's ReleaseKernelOnClose property, but objects instantiated at design time will remain and the corresponding Fire session must be closed manually (the Terminate dialog is to be expected).
Fire connects to the Oracle database in a separate session to Developer 2000. This means that any changes to database information which is being manipulated by Developer 2000 cannot be seen from within the Fire session until the data has been committed to the database.
Delphi can use the Fire Service Object as an ActiveX control
To use the Service Object as an ActiveX control, create and install a FireService package:
From the Component menu, select Import ActiveX Control...
Choose the Formida Fire Service type library and click on Install.
Choose Into New Package and enter the name "FireService". (The package goes in the <delphi>\lib directory, the type library in the <delphi>\import directory).
A package containing the FireService ActiveX control definition is created and installed. The FireService icon is added to the ActiveX palette.
Select the FireService icon from the ActiveX palette.
Add the ActiveX control to the form.
A Fire session will be started if necessary and a control will be created having the following class:
{ FireService object }
{FireService1: TFireService
To use the FireService methods, use the following as an example:
Example:
procedure TForm1.ButtonExecClick(Sender: TObject);
begin
{ Execute a Fire command }
FireService1.Execute('dir');
end;
procedure TForm1.ButtonEvalClick(Sender: TObject);
var
EvalResult: Variant;
begin
{ Evaluate and display a Fire expression }
EvalResult := FireService1.GetValue('ns(~myapp.num)');
MessageDlg('Result = ' + VarToStr(Evalresult),
mtInformation, [mbOK], 0);
end;
procedure TForm1.SetValueClick(Sender: TObject);
begin
{ Set the value of a Fire variable }
FireService1.SetValue('~myapp.str', 'Test');
end;
procedure TForm1.ButtonGetidClick(Sender: TObject);
var
InstanceId: Integer;
begin
{ Get the Service Objects's instance id and display it}
InstanceId := FireService1.GetId();
MessageDlg('InstanceId = ' + IntToStr(InstanceId),
mtInformation, [mbOK], 0);
end;
procedure TForm1.ButtonPanelClick(Sender: TObject);
var
IdStr: String;
begin
{ Execute a macro which uses an embedded window }
IdStr := IntToStr(FireService1.GetId());
FireService1.Execute('exec "c:\\project1\\wtest" (' + IdStr +
')' );
end;
To handle the Fire Service event in the Delphi client, add the appropriate code to the OCX's event.
Example:
procedure TForm1.FireService1FireServiceEvent(Sender: TObject;
const event_string: WideString);
begin
{ Display the passed event string }
MessageDlg('Event string = ' + event_string,
mtConfirmation, [mbOK], 0);
end;
The Delphi syntax for the Service Object's methods, properties and events is given below.
Service Object Methods:
procedure CreateNewObject(out ppObject: IFireService);
procedure Execute(const bstrCommand: WideString);
procedure ExecuteAsync(const bstrCommand: WideString);
procedure SetValue(const variable: WideString; value: OleVariant);
procedure SetValueAsync(const variable: WideString; value: OleVariant);
function GetValue(const expression: WideString): OleVariant;
function Evaluate(const expression: WideString): OleVariant;
function GetId: Integer;
Service Object Properties:
property AppSession: WideString;
property AppStart: WideString;
property AppView: WideString;
property ReleaseKernelOnClose: Integer;
Service Object Events:
procedure TForm1.FireService1FireServiceEvent(Sender: TObject; const event_string: WideString);
Fire adds certain registry keys in order to identify itself as an OLE server, and to identify the Service Object control classes, automation classes and type library. See registry keys section for details.
When Fire runs it will install or update the server and Service Object automation class registry keys automatically. Alternatively fire.exe can be registered without running a fire session with:
fire.exe /RegServer
The Service Object control class registry keys are added when FireService.dll is registered during the normal Fire installation process. If this dll is moved after installation, it can be re-registered with:
regsvr32 FireService.dll
or unregistered with
regsvr32 /u FireService.dll
Note: the Service Object will not start properly until fire.exe has been registered.
You must register the dll as administrator or you may get the following error:
DllRegisterServer in file_name.dll failed.
Return code was: 0x80070005
All Fire OLE registry keys may be removed by running the utility halon.exe.
Alternatively, to remove the Fire Service Object registry keys created by a particular version of Fire, run fire.exe as follows:
file.exe /UnregServerr
The process which controls OLE operations is started at operating system boot time. Consequently when OLE starts a Fire session it passes only the system environment variables that were present at boot time. For the Fire environment variables (MXSITE, MXSYS etc.) to take effect, they need to be moved from the user level to the system level, in Control Panel/System/Environment, and the machine must be rebooted. Similarly if the environment variables are re-assigned a reboot is necessary for them to take effect.
This problem can be circumvented by first ensuring that MXSITE, MXSYS etc. are all relative to a base directory, and then by registering fire.exe with a –env command-line option pointing to the base directory. By default OLE starts a fire.exe session without command-line arguments but the fire entry can be directed to run fire with command-line arguments. Re-registration is done by running fire.exe in stand-alone fashion with the –reg switch, for example:
fire –reg -env=c:/mxroot
This step is usually done automatically when Fire is installed.
These messages indicate that OLE is unable to find the Fire executables. This may arise when Fire has been incorrectly installed, or when the executables have been moved after installation.
Reinstalling Fire and running fire.exe will correct the registry entries.
Errors like "IClassFactory::CreateInstance failed. Class not registered" sometimes occur when fire.exe> has not been registered. Running the executable standalone will automatically register it, but to just register it without starting a fire session use fire /regserver. This is usually done at installation time.
These messages can arise following OLE problems involving Fire and an OLE client, for example, opening a Visual Basic form containing an older version of the Fire Service OCX. It appears that OLE holds on to invalid pointers associated with the Fire Service Object. This causes subsequent attempts to instantiate the Service Object to fail. The problem can usually be cured by deleting the problematic Service Object, then closing and restarting the client application.
This sometimes occurs with older versions of Windows. Check that the latest Windows service pack has been installed. In particular, check that the type library stdole2.tlb is present and has been registered.