Re: VB DLL won't die

From: MacDermott (macdermott_at_NoSpam.com)
Date: 06/09/04 

Date: Tue, 8 Jun 2004 22:32:28 -0400

Many thanks for all of the help I've received on this issue.
I certainly don't have a full understanding of what's going on here, but I
have enough greater understanding to be able to work around this phenomenon,
so I thought I'd at least record what I've found -
    just in case it helps someone else.

My structure was this:
    Access creates a class instance defined in VB6.0. (Test)
    The VB6.0 class creates instance of another class defined in VB.NET.
(NETTest)
    The VB6.0 exposes the VB.NET class instance as a property.
Thus, from Access, I can evaluate properties of the VB.NET class instance,
e.g. Test.NETTest.Volume.
Or so it would seem - and I can actually execute this code.
    But if I do this, then close the Access MDB, Access itself will not
close.

If, instead, I define a property of the VB6.0 class:
    Public Property Get TVolume() as Double
        TVolume=NETTest.Volume
    End Property

I can evaluate Test.TVolume. I get the same value as when I use
Test.NETTest.Volume, but this time I can close Access.

If anyone has any light to shed on this, I'd be grateful -
    but mostly I'm glad it's working again.

- Turtle

BTW if I instantiate the VB6.0 class from VB, instead of from Access, I
haven't experienced this problem.

"MacDermott" <macdermott@NoSpam.com> wrote in message
news:OBGSDzqSEHA.556@tk2msftngp13.phx.gbl...
> I'm posting this question here because I *think* the problem is in the VB
> part of the story, but also because I've gotten such spectacular help here
> on other issues.
> I'll also put something similar in an Access newsgroup, but if somebody
else
> knows another, perhaps better newsgroup for this question, please let me
> know.
>
> Here goes:
> I have a VB DLL which I wrote as part of a VB application. It does a fair
> bit of data manipulation, including reading and writing to an Access
> database. I've been asked to provide a trimmed-down version, with very
> little of the VB graphic interface, and more intensive database
interaction.
> The simple approach seemed to be to use an Access front end, which calls
the
> VB DLL to "do the work" and stores the data back into its own tables.
> I create an instance of a class from the DLL, and a DAO recordset,
then
> I keep feeding the class PKs from the recordset, which it uses to read
data
> into the class, do the calculations, and write them out into a new table.
> At the end, I set the instance = nothing and close up shop.
>
> This was all working fine on my development machine, but then I moved it
> onto a target (production) machine, only to find that Access wouldn't
close.
> I could close the database, but the only way I could get Access itself to
> close was with the Task Manager.
> We tried further, and got it to work well on one other machine, and to
> generate the problem on another.
> The machines where it doesn't work have slightly slower CPUs, perhaps
> slightly less RAM, and for the record are panel PCs, although I can't see
> what difference that would make.
>
> On one of the panel PCs, I opened the DLL's project and ran it in the
> debugger. From there I started Access and ran my application. I put a
> break point in the DLL class's Terminate event. To my amazement, once I
had
> stopped execution there, I couldn't seem to get out of that event. I
> removed the breakpoint and pressed F8. The yellow highlight went away,
but
> I couldn't get back to the Access application. If I hit the Break button
on
> the menu, the yellow highlight would come back to the same line of code
> where it had been. I could manually move execution down a line and repeat
> the sequence - the highlight came back on the new line.
>
> Any ideas what could be causing this?
> - Turtle
>
>