Weird behaviour, dll calling

[b.ploetzeneder]

Hi,

We've run into some slightly buggy behaviour when calling dlls., and we would like to understand or at least fix it. (Unfortunately we aren't allowed to upload running files, but I've got some screenshots)

The program runs on two systems, both identifically configured, LV2010, WinXP32.
The situation occurs when loading a dll.
The dll and loading is okay with system A, with system B it doesn't work.
The problem is the following: Whenever we close the VI, it changes the name of the dll from api32.dll to Api32.dll.
This doesn't happen with system A, but it definitely stops the software from finding the dll.

I've tried to change the path into a constant input, but it doesn't seem to help.
Does anyone have an idea what is happening?
Thanks,
Birgit

[Jan_Wagner]

Hi Birgit,

I have done some testing and the Dll-calling is case insensitive. Therefore I'm guessing that the problem is caused by something else. Can you elaborate what you mean with the step "loading a dll"? Are there any messages popping up (Screenshots if possible)?

I have tested the behavior on a German and an English System. What do you mean with "identically configured". Is it the same image that is used or is it just the same OS and the same LV versions? But even if it is the same image there can be different settings so it's hard to tell.

Thanks for your answer,

Jan

[b.ploetzeneder]

Hi,

thanks for playing around with this (and the information that it is not case-sensitive, but the changing behaviour is still suspicious), with loading the dll I mean the call inside the block diagram.

We've set it up on two identical systems with iamges (basically same computer, same OS, same LV, just a few hundreds of kilometers apart) a year ago or so. Theoretically, they are identical, but I'm starting to suspect a update or something similar. A clean reinstall is only a last resort, though.

There's no error message, the subvi just gives you the default values, as configured, but that external library doesn't seem to have LV-compatible error handling.. But I'll have someone work on extracting more information on that and can get you back tomorrow (not in the office today..).

I've never had problems with my own dll-dependencies, they just worked ... can you name me some places where the problem could hide?

Thanks a lot for your time,
Birgit