VB Error Code Generation

[jbrewer]

Hi. I'm getting a strange overflow error when control returns to VB from a DLL. The error does not occur on the DLL call line, nor on the line after. It occurs on the first attempt to assign a real number to a variable declared as single precision. Assignmenst to integers, boolean, etc., do not generate the error message. The error message should not occur as a result of the assignment statement. (X = 10).

My question is, how does VB generate error conditions? Why would the statement X = 10.0, result in an overflow when the previous line X_int = 10, works fine, provided X_int is declared as an integer.

Is something being passed through the DLL argument list that I can't see? Something that inadverdently generates a VB error interrupt?

I am completely stumped here as the interfaces ARE solid. The problem is NOT the interfaces but is either an inherent limitation of VB, (visual studio 6.0) or something in the DLL that is corrupting VBs memory.

I'm desperate at this point!!!

 

[gumby451]

Are you setting an integer value = 10.0? If so, this will generate an error because an integer will hold only "whole" numbers. If you would like to set a variable = 10.0, declare it as a double.

 

[jbrewer]

Assume that I really know what I am doing and have thoroughly checked out all the interfaces and everything obvious.

As far as the assignment statement goes, it doesn't matter how I assign the variable, whether I assign a variable to a variable or a variable to a constant or try an arithmetic operation of some kind. (Doesn't work with doubles either)

To make it extra safe, I have tried things along the lines of

Dim X As Single
.
.
.
X = Csng(10)
and
X = Y (with Y declared as Single)

There's nothing special about X=10. It is just a line I stuck in there for debugging purposes because it is more certain than the line that originally caused the problem. Same problem though...

I'm outta ideas here and am looking for some little known nuance of VB concerning memory usage, error generation, DLL interfaces or something like that. I've been doing this for years and this is the first time I've had trouble like this. Could I be looking at a compiler bug or something like that???

 

[chiph]

jbrewer -

I'm guessing memory corruption either inside the DLL or as a result of calling the DLL.

Can you create a "stub" version of the DLL that all it does is return success after calling one of it's functions? This would eliminate the possibility of code inside the DLL causing the problem.

Chip H.

BTW. Are you the same jbrewer who worked for rtmobile?

 

[jbrewer]

If you owe the rtmobile buy money, yes, that's me! Actually, no. I'm with CSC.

As far as the stub version goes, that is going to be my next step. Work my way down the call chain until I finally eliminate the offensive line buried somewhere deep down there. Let's hope it's not too deep.

-john