Overflow error when calling a function of a user defined object

[fakewalrus]

Working with Excel 2010 Version 14.0.6023.1000 (32 bit)...

I have a project with one Class Module called "Stream"
Inside that class module I have a public function "SpecifyFromUser"

Public Function SpecifyFromUser(SpecPressure As Double, SpecTemperature As Double, SpecMolComp() As Double, Optional SpecMolFlow_lbmolhr As Double, Optional SpecMassFlow_lbmhr As Double) As Long

(Code that performs a bunch of thermodynamic calculations 
and stores the results such as flow rates, enthalpies, etc, into private variables in the class module)

End Function

My main subroutine that I am executing is in its own separate module called "CycleCalc"
I also have a number of utility subroutines that reside out in a separate module, for example "IsExpander".
I want the various utility functions to have the capability to manipulate streams that I define in "CycleCalc".
To achieve this, I make the various calculations and then I use the "SpecifyFromUser" function from within this subroutine to manipulate the target stream.

Public Sub IsExpander(InputStream As Stream, OutputStream As Stream, SpecIsEff As Double, SpecDischargePressure_psia As Double, CalcHP As Double, CalcHead As Double)
    
Dim DummyOutputPress(0) As Double
Dim DummyOutputTemp(0) As Double
Dim DummyOutputMolFlowrateByComponent() As Double
Dim NComp As Long

On Error GoTo ErrHandler

NComp = InputStream.NumberOfComponents
ReDim DummyOutputMolFlowrateByComponent(NComp - 1) As Double

(Code that calculates DummyOutputPress(0), DummyOutputTemp(0), DummyOutputMolFlowrateByComponent)
(F_to_R is a public constant defined elsewhere)

Dummy = OutputStream.SpecifyFromUser(DummyOutputPress(0), DummyOutputTemp(0) - F_to_R, DummyOutputMolFlowrateByComponent)

Exit Sub

ErrHandler:
Resume

End Sub

I start off defining all the various streams I have in the "CycleCalc" subroutine, e.g.

Dim E1 As Stream: Set E1 = New Stream
Dim E2 As Stream: Set E2 = New Stream

Then I go down and initialize the streams inside the "CycleCalc" procedure using my "SpecifyFromUser" function

Dummy = E1.SpecifyFromUser(Range("E1_Press").Cells(1, CaseNumber).Value, Range("E1_Temp").Cells(1, CaseNumber).Value, LiqFeed_MolComposition, , Range("E1_MassFlow").Cells(1, CaseNumber).Value)
Dummy = E2.SpecifyFromUser(Range("E2_Press").Cells(1, CaseNumber).Value, E1.Temp_F - 150, LiqFeed_MolComposition, , E1.MassFlow_lbmhr(2))

Everything works great so far. There are no errors associated with the "SpecifyFromUser" function when it's called from within the main "CycleCalc" procedure, but then I get to a part of "CycleCalc" where I call one of the utility subroutines and pass in some streams to it.

Call IsExpander(E1, E2, 1, E2.Press_psia, E_hp, E_Head_Is)

The "SpecifyFromUser" function seems to almost always result in a #6 Overflow error being raised whenever I call it from inside one of my utility subroutines, such as "IsExpander". It seems that the error is raised before it actually enters into the "SpecifyFromUser" function, i.e. the debugger seems to take offense to the arguments that I am passing.

BUT the stangest thing is that I have an error handling routine inside the "IsExpander" code and if I use "Resume", the code will proceed as though nothing is wrong. I think for the most part my whole system could work if I just setup the error handlers in all of my various utility routines and tell them to Resume, but I suppose this is adding overhead time as execution jumps to the error handler, sort out whether the error is the predictable sort or other, then returns back again. I would much rather not have the error in the first place.

Also I thought it might be the nature of setting up "SpecifyFromUser" as a function where the return value is really just a dummy, rather than a Sub, but setting it up the other way does not change anything....it still has the same error in the same place.

 

[fakewalrus]

Some additional detail....

I had the idea that maybe somehow the fact that the "OutputStream" in the "IsExpander" subroutine was already initiated in the main routine was causing the sort of problem I was experiencing, so I tried the idea of introducing a new Stream "OutputTemp" inside the "IsExpander" subroutine, and then trying to copy back to the real Output Stream at the end.

Before I even got the implement the part about copying back at the end, I found that even if I introduced a fresh stream name within "IsExpander" it would still have the same issue when I tried to use the "SpecifyFromUser" function within the "IsExpander" routine.

One other factor that I did not mention was that inside the "IsExpander" subroutine (as well as throughout the project) there are function calls to a .dll that I believe contains a bunch of Fortran Functions. The Fortran functions are sort of notoriously prone to "meaningless" overflow errors of the sort I am experiencing, where you can just Resume and everything appears to keep working as it should. Furthermore, it seems as though sometimes when one of these functions is called and it raises an overflow error, VBA cannot identify it until the next line, e.g. if there is no error handler in place, the VBA debugger does not raise the error flag until the next line of VBA code after the function call. HOWEVER, in my current situation I can install some lines of code between the last .dll function call and where my error is showing up, and execution seems to move on through the .dll funciton call with no errors right up to where I call "SpecifyFromUser" and then the error gets raised. Could it be that an error is "latent" (?) for several lines and only manifests itself later, say when I first attempt to access one of the parameters returned from the function call?

I have also attempted to change the arguments in my "SpecifyFromUSer" call to just hard values. This also does not seem to make the problem go away.

 

[fakewalrus]

Update....

In my addendum below, I mentioned the idea...

"Could it be that an error is "latent" (?) for several lines and only manifests itself later, say when I first attempt to access one of the parameters returned from the function call?"

Further exploration seems to prove this idea true.
The error gets raised when I try to use one of the resulting parameters that results from the .dll function call, NOT on the line of the function call itself or on the line immediately subsequent. If I insert code after the function call that does not use any of the parameters resulting from the function, this code does not raise any error.

I have used "Option Explicit". The return parameters are all Doubles and arrays of Doubles. They are all "Dim"ed as such.
I can look inside the "Locals" window and it sure looks like all the parameters are correctly dimensioned and they appear to have legitimate values in them.
Also if I try to use CDbl() on one of the returned arguments, that also does not seem to stop the error from happening.

Very frustrating / confusing.....

 

[fakewalrus]

Ok...I'm definitely starting to get warmer here (but still can't quite figure it all out) ...

I am pretty confident that the errors come when I try to take a parameter that was calculated in one of the FORTRAN function calls and use it in an expression in VBA.

...but I can't quite crack the code of what does it?
I am passing lots of variable sin an out..they don't all blow up(?)

And why doesn't CDbl() do anything to help me?