Board index » delphi » Help !!! Runtime error 216

Help !!! Runtime error 216

I put into a DLL some forms that use Diamond Access (BDE replacement for
Access 97 Databases with DAO 35). When the program calls a Form the DLL
create it, opens
a DAODatabase and a DAOTable (in FormCreate) and all run ok. When I close
the form, I close the DAOTable and DaoDatabase and all run ok too. But when
I close the EXE i receive a runtime error 216.

What object I forget to destroy?

Thanks.

 

Re:Help !!! Runtime error 216


Quote
>I close the EXE i receive a runtime error 216.

>What object I forget to destroy?

In building my own comserver / client solution, I discovered that if any
com-interface is not being set to nil (in fact-close it down), I got a 216
runtime-error created in the OLE32.dll

It happened when the last windowhandle was destroyed (I traced it down to
Controls.pas)

I have no Idea if your solution uses a com-interface, but if so  this might
be the problem.

Re:Help !!! Runtime error 216


I posted this on 7/6/98 regargind the Infamouse 216 Error:

I've recently discovered that the following line of code in your main form
seems to help in many cases:

initialization
begin
  CoInitialize(nil);
end;

(CoInitialize is in the ActiveX unit).

My investigation (via source code tracing and event logging) lead me to
believe that Delphi was trying to free modules that were no longer loaded or
was trying to access modules (DLL's) that were no longer loaded. Can't say
for sure this is the problem but this one line of code has solved a
persistent / consistent problem I had in three applications.

Let me know if it helps in your case.

Quote
Marc Carreras wrote in message <6nsvd8$ga...@forums.borland.com>...
>I put into a DLL some forms that use Diamond Access (BDE replacement for
>Access 97 Databases with DAO 35). When the program calls a Form the DLL
>create it, opens
>a DAODatabase and a DAOTable (in FormCreate) and all run ok. When I close
>the form, I close the DAOTable and DaoDatabase and all run ok too. But when
>I close the EXE i receive a runtime error 216.

>What object I forget to destroy?

>Thanks.

Re:Help !!! Runtime error 216


Don't you also have to call CoUninitiaze for every call to CoInitialize?  
If so, I guess you could call it in the finalization section.

In article <6oj5ij$7...@forums.borland.com>, rja...@horizonrealtime.com
says...

Quote
> I posted this on 7/6/98 regargind the Infamouse 216 Error:

> I've recently discovered that the following line of code in your main form
> seems to help in many cases:

> initialization
> begin
>   CoInitialize(nil);
> end;

> (CoInitialize is in the ActiveX unit).

> My investigation (via source code tracing and event logging) lead me to
> believe that Delphi was trying to free modules that were no longer loaded or
> was trying to access modules (DLL's) that were no longer loaded. Can't say
> for sure this is the problem but this one line of code has solved a
> persistent / consistent problem I had in three applications.

> Let me know if it helps in your case.

Re:Help !!! Runtime error 216


Do you put this in the Client calling the Automation server, or in the
Automation Server itself?

thx

Re:Help !!! Runtime error 216


Quote
Grant Johnson wrote:
>Don't you also have to call CoUninitiaze for every call to CoInitialize?

I>f so, I guess you could call it in the finalization section.

Quote
Dilbert wrote in message
>Do you put this in the Client calling the Automation server, or in the
>Automation Server itself?

I put the code in the client calling the server. If the server has the same
problem, I put it there too.

Yes, you should call CoUninitialize for every call to CoInitialize, however
if you do in this case the 216 error comes back. Since many parts of WinNT
4.0 O/S use these DLL's and they are already loaded, I don't see much harm
in leaving them laying around in memory. My clients are very upset with the
"216" dialog box however. It appears that Delphi 3 is helping too much in
hiding the COM implementation details. Delphi 4 claims to let you control
when CoInitialize / CoUnitialize is called however even the readme file for
the example programs admits they have 216 errors they can't resolve. Much to
my dismay, VB 5.0 handles my servers fine w/o any exiting GPF's.

Tracing my app with Turbo De{*word*81} (32-bit version), I detected the GPF
inside a call to security.dll. I can't determine where in VCL this call is
made from. Security.DLL is part of the set of Microsoft supplied OLE DLL's.
I get this error usually when using DCOM. I can control whether or not my
app gets the GPF by activating my local objects first then the DCOM objects
or vice-versa. CoInitialize takes care of in either case. BTW: I tried
taking care of security explicitly in my code with CoInitializeSecurity but
this didn't help.

Rob.

Other Threads