Ocx using dao gives error upon exit when used in .NET app

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I wanted to use some of my MFC stuff in a new C# applikation, so I made an
activeX/ocx of my a database viewer. Tested ocx i VB 6.0 and MFC app, worked
fine. Tested ocx i a C# .NET app, and upon exit I get ".NET
BroadcastEventWindow 1.0.5000.0.2" error.
Some debugging indicates that the error occurs in AfxDaoTerm:
pDaoState->m_pDAODBEngine->Release();

Anyone know the solution to this one ?
 
Hi pafgbs,

When you calling an MFC object in the managed code(e.g. a C# program), some
COM references are not released on the exit , so you need to force the
garbage collection explicity right before exiting your managed application:
...
System.GC.Collect();
...


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
 
Thank yuo for yuor ansver, unfortunately I still get the error.

To test this error is easy, in VC++ 6.0 just start the new project wizard,
select "MFC ActiveX Controlwizard" and accept all defaults. Add an OnCreate
handler in the control with code like this:

int CMyCtrl::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (COleControl::OnCreate(lpCreateStruct) == -1)
return -1;
CDaoDatabase test(NULL);
try
{
test.Open(_T("c:\\test.mdb"));
}
catch( CDaoException* e )
{
e->Delete();
}

return 0;
}

In the app object's ExitInstance() add AfxDaoTerm call to avoid ASSERT in
CWinApp::ExitInstance.

Using this ocx in any windows app made with .NET 2003 will produse an error
upon exit.

If I try to call System.GC.Collect() before exiting Main, like this:

static void Main()
{
Application.Run(new Form1());
System.GC.Collect();
}

the error message will after the call to the garbage collector has finished.
 
Hi pafgbs,
...
Click to expand...

OK, I can repro this problem on my side. According to the info from the
call stack, it appears the problem happens when your MFC control calling
the AfxDaoTerm().

I think maybe you call the AfxDaoTerm() too later, when it is executed in
your control's ExitInstance(), the corresponding DAO object/reference has
already been collected by the GC. So you need to call the AfxDaoTerm() in
the MFC control's destructor, it would be OK :)

CMyCtrl::~CMyCtrl()
{
// TODO: Cleanup your control's instance data here.
AfxDaoTerm();
}


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Ok, this seems to work, thanks :-)
I might get in trouble later when adding several other controls to the ocx,
but som household code might fix it. I still dont get why GC should have any
buisness collecting a reference counted object allocated in my ocx without
its knowledge, but hey, what do I know.

Thanks
 
I might get in trouble later when adding several other controls to the
ocx,
but som household code might fix it. I still dont get why GC should have any
buisness collecting a reference counted object allocated in my ocx without
its knowledge, but hey, what do I know.
Click to expand...

Next time if you get the similar problem which involved the unmanaged
object, I suggest you can also post that problem to the newsgroup
dotnet.framework.interop.


Good Luck!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top