Strange Compiler Error With Call Library Node

[smercurio_fc]

In another thread I posted an example of how to use the Windows API to prevent a window from being dragged by removing the "Move" menu item from the System Menu. When creating this VI I found this strange problem with the LabVIEW compiler. I found that if I wired the error clusters between the Call Library Nodes and then try to save the VI I would get this error:



This would happen every time, even if restarting LabVIEW and recreating the VI from scratch. I don't recall ever seeing this before. I've attached the VI, which is written in 8.20. Can others confirm this behavior?

Thanks.

Message Edited by smercurio_fc on 08-01-2007 08:57 AM

[chrisger]

hi there

works perfectly well at my LV 8.20 XPSP2

[smercurio_fc]

Hmmm... That's really strange. I tried this numerous times under various conditions and always had that error. Can you post the VI with the error clusters wired up so I can try to see what might be going on? Thanks.

[chrisger]

there you are....

[smercurio_fc]

This has got to be one of the more bizarre things I've seen with LabBVIEW. There is a difference between your modified version and mine. The first Call Library Node in your version had a path to the user32.dll changed to "..\..\WINDOWS\system32\user32.dll". The others were still set to "C:\WINDOWS\system32\user32.dll". In my original VI all Call Library nodes were set to "C:\WINDOWS\system32\user32.dll" for the DLL location. When I changed the first Call Libary Node to point to "C:\WINDOWS\system32\user32.dll", deleted the error cluster wires and reconnected them, and then try to save the VI I got the same error I mentioned before. When you opened my VI did LabVIEW try to do a search for the DLL? It shouldn't have since the path was set explicitly.

[chrisger]

whoww.....

well, i changed nothing with your original CLNs. But when i insert the full path to MY user32.dll i get the SAME error like you when i try to save the VI with the error clusters connected.

BUT: When i remove the path from the CLNs and just insert "user32.dll" in "Library name and path", then all works fine. maybe you have to reopen the VI after the changes to relink the dll, but LV will find the dll on any system because user32.dll is inside the systems search path. i think the reason for this error is the full path to a systems - dll (the path to the systems directory is not equal for all platforms). for systems dlls the name is sufficient.

[smercurio_fc]

Strange indeed. I don't quite get why the path would have anything to do with it, but it definitely seems to be related to it. Perhaps if someone from NI is listening they can shed some light?

Thanks for the effort.

Message Edited by smercurio_fc on 08-02-2007 09:21 AM

[Jarrod_S.]

This could be an issue that was fixed in 8.2.1. I found a similar sounding issue in the Readme:

"Fixed an issue where a VI that contains a Call Library Function Node breaks when compiled if you wire the error in terminal of the node but not the error out terminal."

Also, Chris's version that wasn't broken always had the error out wired when the error in terminal was wired, and your version wasn't broken until you started wiring the error terminals. If you post a definitely broken version from 8.20, I can load it in 8.2.1 and verify this.

[chrisger]

my description about the full path of the systems dll inside the CLNs seems to be irrelevant for the behaviour (i just wasn't aware about the errorIn and -Out thing).

but anyway i'd prefer to insert the name of a systems dll instead the full path.

[smercurio_fc]

Jarrod,

Here's a broken version.

Changing the location of the DLL to say just "user32.dll" has no effect, so I suspect the issue is what you mentioned.

Thanks for checking.