Prompt the user to see if the application is properly registered in the database and/or to reinstall the application.Once your application has initialized the OLESERVERVTBL structure, it needs to initialize the OLESERVER structure, setting the LPOLESERVERVTBL to point to the OLESERVERVTBL previously initialized.
OLE server applications must unconditionally register themselves with the server DLL by calling the OleRegisterServer function. The class name passed in OleRegisterServer must match the class name set in the registration database for the object class.
Note An SDI server application should never register itself as a single-instance server; doing so will prevent the application from starting other instances of itself to edit objects. Instead, an SDI server application should register itself as a multi-instance server by specifying OLE_SERVER_MULTI for the OleRegisterServer function).
An MDI server application can be either a single-instance or a multi-instance server. MDI server applications registered as a single-instance server tend to have improved performance over MDI applications registered as multi-instance servers.
The following code example registers the SRVRDEMO.EXE program with OleRegisterServer:
/* Initialize the server by allocating memory for it, and
* calling the OleRegisterServer method. Requires that the
* server method table has been properly initialized.
*
* HWND hwnd - Handle to the main window
* LPSTR lpszLine - The Windows command line
*
* RETURNS: TRUE if the memory could be allocated, and the
* server was properly registered; otherwise,FALSE
*/
BOOL InitServer (HWND hwnd, HANDLE hInst)
{
srvrMain.olesrvr.lpvtbl = &srvrvtbl;
if (OLE_OK != OleRegisterServer (szClassName,
(LPOLESERVER) &srvrMain, &srvrMain.lhsrvr,
hInst, OLE_SERVER_MULTI))
return FALSE;
else
return TRUE;
}
Note If an OLE server application is also a DDE server, the class name passed to OleRegisterServer cannot be the same as the application's module (executable) name. This is because the server DLL communicates with the server application through DDE and attempts to initiate a DDE conversation with the server using the name given in OleRegisterServer. If the application uses the same name as that used for DDE, then OLE and non-OLE conversations will overlap and the libraries will not know which application initiated the DDE conversation. Typically, the OLE application name changes since other applications and users depend on the original DDE service name.
If OleRegisterServer returns OLE_OK, then the third parameter contains a pointer to a handle that gets passed to future OLESVR.DLL calls, such as OleRegisterServerDoc. This handle needs to be stored where it will be globally accessible and at the same time associated with the OLESERVER structure. Storing it directly in the application's OLESERVER structure meets both needs.
If OleRegisterServer returns anything other than OLE_OK, the server application should fail initialization and terminate.
An error registering the application with OleRegisterServer often indicates a data problem in the system registration database; in this case the server application can:
Prompt the user to see if the application is properly registered in the database and/or to reinstall the application.
Use the SHELL.DLL API functions to reregister itself in the system registration database, then register with OleRegisterServer (this happens without the user's knowledge.) For more information on using the SHELL API functions to register a server application, see Chapter 10, "Using the Registration Database."