phantom Excel process with remote VB6 dll

[lalbatros]

Hello,

I remoted most of my number crunching stuff to a dll.
It work fine except for a few strange things that I observed like from time to time a strange message "Error in loading DLL" even though everything works fine. This message appears only when entering the main formula in the formula, and is no problem at all in usual work.

When I investigated, I noticed in the "windows task manager" that one instance of excel remains open even after I have closed excel. This phantom excel process is maybe related to the other problem I explained above.

How does my application work? Very easy!
Instead of calling a VBA function, it creates a VB6 object from this dll and uses the methods of this object. In this way I have remoted the number crunching functionality.
The main parameter passe in this process is a reference to the original workbook. I need it because the number crunching functions need to read data from the workbook.

I made it sure to terminate the life of the object properly on both sides by ad hoc obj=Nothing statements.
Still I think that the "garbage collection" or the "terminating" is the cause of the problem.

Any idea?
I would appreciate your suggestions quite a lot since I want to make everything clean and safe for my end users.

thanks

 

[xld]

What does the code in the DLL for communicating with the Excel instance look like?

 

[Legacy 98055]

Please explain "remoting"? DLLs are typically loaded into the same process space as the client. The definition of remoting would require a separate process and therefore, as far as VB6, an ActiveX.exe, as opposed to a dll. It sounds as if your mystery "VB6 object" is holding onto Excel by way of a reference or even creating one it's own instances. Need to see your code. All of it.

 

[lalbatros]

xld,
Right_Click,

The dll receives a reference to the calling workbook.
Starting from this references, it collect information from this workbook.
Then it performs a lot of calculations and stores them internally.
The calling workbook can then get the results by calling other functions from the dll.

I used "remoting" why my own meaning: simply doing the calculations in a dll instead of in a VBA project.
This application is working since 8 years in the old way, using a VBA project.
Now I am preparing a new version that will be based on a dll for many good reasons.

I said talked about a "phantom Excel process" simply because I see an "Excel" entry even when the application has been closed. In addition, I see two entries when the application is running (the functions have been called once). I don't know precisely what is meant by a process".

However, I have the feeling that it is not good to leaves things as they are now. I saw that the number of phantoms could grow and I guess this might cause a problem for some users at the end of the day. Isn't it? So I would like to avoid a problem, and I would prefer to avoid explaining to the users that they need to end a pile of precesses from time to time ...

Thanks for any suggestion.
If this was not a e-forum, I would offer some chocolate for your help !

 

[Norie]

Any chance of seeing some code?

When automating Excel from other applications eg Word if you aren't referencing things properly then you can end up with a 'phantom' instance.

 

[Legacy 98055]

Please post ALL of your dll code and the code within your workbook that creates an instance of your vb class... Also, if neccesary, provide us with an example of how you use your class...

 

[lalbatros]

xld,
Right_Click,

I checked that the reference workbook received by the dll run within the excel instance that was opened first. This is quite ovious of course, but I checked it by "quitting" this wb.application.

I am almost sure that I will not be able to find an object used within the dll that would be linked to another instance of excel. Yet, there is a new instance that is created.

And since I have no "handle" to this phantom instance, I cannot close it ...

Now I understand the problem, may be this helps ...

 

[lalbatros]

xld,
Right_Click,

I cannot leak the whole code here, as you may guess.
However, on the excel side the code is now very simple:

Public mdl As Object

Function modelOpt(ParamArray handles())
    Set mdl = CreateObject("recipes2008.recLib")
    mdl.setWorkbook ActiveWorkbook
    vhandles = handles
    modelOpt = mdl.modelOpt(vhandles)
End Function

Function modelStatus(handle)
    modelStatus = mdl.modelStatus(handle)
End Function

Function modelSolution(handle, Rlbls)
    modelSolution = mdl.modelSolution(handle, Rlbls)
End Function

Function modelEval(handle As Range, RlabelNames As Range, RlabelLike As Range, Rtons As Range, RQ As Range)
    modelEval = mdl.modelEval(handle, RlabelNames, RlabelLike, Rtons, RQ)
End Function

Function modelCheckConstraint(mi, ma, va)
    modelCheckConstraint = mdl.modelCheckConstraint(mi, ma, va)
End Function

Function modelSensibilities(handle As String, Rlbls As Range, what As String, infinity As Double) As Variant
    modelSensibilities = mdl.modelSensibilities(handle, Rlbls, what, infinity)
End Function

Function modelDuals(handle, Rlbls, RQ, RMin, RMax, what)
    modelDuals = mdl.modelDuals(handle, Rlbls, RQ, RMin, RMax, what)
End Function

On the dll-side, the code is exactly the same, except that the number-crunching is fully developped and that there are private auxiliary methods supporting the main functions.

Most of the interaction with excel on the dll side is in the remoted version of the method "modelOpt".
The method essentially reads several ranges and then calculates results to be read later from excel.

Before remoting to a dll, all interactions with excel where performed from the ActiveWorkbook object.
With the dll, these interactions are based on a ThisWorkbook reference that is set in the statement "mdl.setWorkbook ActiveWorkbook" above. It is difficult to be simpler. As you can see I did not change anything to the code, just making it remote.

 

[Norie]

ActiveWorkbook?

Could that be your problem?

 

[lalbatros]

Norie,

I don't see why referencing "ActiveWorkbook" could be a problem.
This is the object I need to pass to the dll for further processing.
No idea why as soon as I pass the border with this object I create a new instance of Excel.

Note: I have not really tested that yet, I only observed what happens when I pass this object and complete the other things. I will try.