Problem with atof within a C++ DLL which is used in Labview 6.1.

[Sven Bone]

Hello,
I have a BIG problem. I use a C++ DLL in a LabView program. First I tested the DLL in a C environment and everythings works well!

The DLL reads somes parameters from an INI file and converts the read strings with the "atof" command to a double value which is internally used in the DLL. That's works perfectly in the C environment. But when I use the same DLL in LabView, the conversion from a string to a double parameter fails. All values are rounded. (e.g. 0.85 --> 0 or 1.34 --> 1).

I have no idea what's going wrong. Another problem is, that I can't debug the DLL in the LabView environment, which makes it very difficult to locate the bug.

Thanks for your help in advance.

[rolfk]

Sven Bone wrote:

> The DLL reads somes parameters from an INI file and converts the read
> strings with the "atof" command to a double value which is internally
> used in the DLL. That's works perfectly in the C environment. But when
> I use the same DLL in LabView, the conversion from a string to a
> double parameter fails. All values are rounded. (e.g. 0.85 --> 0 or
> 1.34 --> 1).

Seems like a decimal point problem to me. Are you sure the string passed
to the DLL is in the correct format? If that is the case your local
settings are probably an issue. Not sure what ANSI says but the MSVC
runtime libraries certainly use the localized settings of the number
format. You can set that in the Control Panel->International Settings.
If this difference is happening o
n the same computer, you are in for
some serious head cratching as why that DLL does use a different atof
implementation when testing in C or LabVIEW.

> I have no idea what's going wrong. Another problem is, that I can't
> debug the DLL in the LabView environment, which makes it very
> difficult to locate the bug.

Well, you can debug in LabVIEW 6.0.x. After that setting the VI to
non-debug is supposed to generate normal exceptions instead of catching
them in LabVIEWs own exception handler but somehow it does not seem to
work that way for me.

Rolf Kalbermatter
>
> Thanks for your help in advance.

[Sven Bone]

Today I will check the localized settings. That could be one possible solution.

The C-Environment and the LabView environment are running on two differnt PCs. But I am sure, they are using the same MSVC libraries because I installed them on both PCs from the same CDROM.

You ask me, if the string I passed to the DLL is ok? I do not pass any string into the DLL. A function within the DLL reads the strings out of an INI file and converts all necessary parameters to a double value (atof). These parameters are completly used within the DLL. There is no exchange between LV and the DLL.

Sven Bone

[rolfk]

Sven Bone wrote:

> Today I will check the localized settings. That could be one possible
> solution.
>
> The C-Environment and the LabView environment are running on two
> differnt PCs. But I am sure, they are using the same MSVC libraries
> because I installed them on both PCs from the same CDROM.

Well, this information almost certainly means that the localization is
the problem. I was half assuming that you would test both versions on
the same PC as that is what I usually do and then this problem would be
rather tricky, but in this case I'm quite sure you have a localized
setting on the computer you try the LabVIEW test on which uses the
opposite decimal character than what is in the INI file, assuming that
the INI file is the same on bo
th platforms.
Alternatively the INI file writing could be platform dependant and the
MSVC runtime you use is not.

Rolf Kalbermatter