References to sub-VIs and DLLs

[dgholstein]

Yes, that is what I'm experiencing.

   ...Dan

[JLS]

Hi again,

I don't think I'm seeing the same behavior - here's what I'm thinking and experiencing.  First, I think we should see this problem with just a plain exe, since the exe will have to be built under the installer, which will later just install it.  Thus, I set out trying to break things by building an exe.  So here's what I did (all in 7.1):

0. everything below is using the same add.dll and subtract.dll discussed in this thread.

1. created a LabVIEW-built exe from Call Add Dll.vi (its name gives away its functionality) using the add.dll and made sure it added as expected (I had to make the CLFN be "Reentrant" instead of "Run in UI Thread" but that is a known bug - if this doesn't make sense already just ask and I'll explain further)

2. opened Call Add Dll.vi and changed the CLFN to point to subtract.dll (and to the add function inside, which actually performs subtraction) and then saved and closed the VI (even if you don't close it, when you build an exe, it will ask you to close any VIs used in building the exe).

3. built the exe again using the same build script as defined for and used in step 1, and indeed, the subtraction operation was performed as expected.

So, as long as you have saved your VI after pointing it to a new dll, you should be ok... even if you don't close the VI, it'll make you close it and build the exe after that VI is closed (I did try it this way as well).  To be totally sure, I tried to trick the exe builder by opening the Add.vi which actually adds two numbers, but pointing Call Add Dll.vi to the subtract.dll function (which subtracts despite the name add, and more importantly is based on a VI named Add.vi which actually subtracts).  Now, in the LabVIEW development environment, I can easily "choose" whether I want addition or subtraction to occur in Call Add Dll.vi, if before opening Call Add Dll.vi I just open whichever version of Add.vi I'd like (the one that adds or the one that subtracts), I can definitely make Call Add Dll.vi either add or subtract, regardless of which dll I'm pointing to because LabVIEW underneath is looking to load Add.vi since that is what both dlls use, and since it's already open under my scenario, it won't go looking for it.  HOWEVER, I observe that even if I get my Call Add Dll.vi into a state where, for example, I'm pointing to add.dll, but I have already opened Add.vi which actually SUBTRACTS, that if I build the exe, it will still take the Add.vi which ADDS, and NOT use the one which subtracts as the Call Add Dll.vi in the development environment would have done.

Thus, I think I'm seeing different behavior than you.  Just for sanity, can you try rebuilding an exe or an installer under similar circumstances?  If you could just disable the installer buidling from your tab, it will save some time actually.  Hopefully you'll find that your exes build like I've described above, which is to build correctly according to which dll you've selected in your CLFN, regardless of which version of (in my case) an Add.vi I have open while building the exe.

This has been an interesting discussion, so I definitely want to make sure we're on the same page about everything!

Thank you again,

Best Regards,

JLS

[dgholstein]

JLS;

Thanks again.  I see what your seeing when building an EXE.  It's when I build an MSI with the EXE, and install that on a completely different machine where I encounter the problem.  It seeks the old name.

The attached PNG is a typical hierarchy of my programs (Acceptance Test Procedure, ATP).  I suppose that if LabVIEW included the CLFN DLL calls in the hierarchy, that would help me out a lot.  As it is, the hierarchy is very helpful with identifying the full path of all the sub-VIs (by hovering) and if that sub-VI is in a "changed" state (with an asterisk).   I would like to see the LabVIEW hierarchy identify the full path of the DLL and call out the function being called.

   ...Dan

[JLS]

Hello,

The fact that this happens only with an installer build is interesting - I'll play with this and hopefully confirm that behavior.  Unfortunately it's not likely that this is going to be fixed for 7.x, since the issue was addressed for 8.x.  However, hopefully I'll be able to find a nice way to get around it... hopefully 🙂

Your suggestions on the other hand are very good - we love to receive suggestions, in fact, product suggestions are one way for customers to interact directly with R&D (one of the only ways actually).  If you have time, filing those formally at our site would be great, where you can include other details you'd like to see.  Just click the "feedback" link in the lower left corner of the Contact NI page, linked from ni.com.

I will post again with the results of my installer exploration!

Best Regards,

JLS

[AlexDubya]

Hi everyone,

I thought it would be prudent to point out that in my experince in the last week with this problem my version of LabView 8.2.1 exhibits the same behavior when using CallLibraryFunction and using the Tools->Import->Shared Library.

When I use "specify on diagram" in a CallLibraryFunction dialog box the path I wire up to the terminal DOES NOT guarantee what DLL will be called. Note that I have been using similarly named DLLs and differently named DLLs. In both cases the only way I have found to guarantee what DLL will be called is to specifiy the path manually in the CallLibraryFunction dialog (and for all of these this is tedious) and to close and reopen the LabView project.

This becomes a problem when using updated DLLs.  Selecting Import Shared Library does not guarantee which DLL will be called either (I was able to test and recreate this using VisualStudio's attach to process debugger feature). What is the prefered practice or "correct" way of managing this?

-Alex-

[NoahR]

Hi Alex,

Thanks for contacting National Instruments.  Have you tried using the "Update VIs for a shared library" option when trying to import the shared library?  This could be an option for you when changing the DLL.  I have attached a link below that goes through some of the steps for implementing this.  I would say that the preferred practice for specifying the path for the DLL is selecting the file in the dialog box from the Call Library Function VI.  Please let me know if using the Update option does not work for you or help you out with your changing application and we can definitely go from there.  Thanks!

http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/example_import_shared_library/

[AlexDubya]

Noah,

When I use Tools->Import->Shared Library and select Update it will change EVERY Call Library Function node in the VI even ones that don't use the one I am changing.

For example:

If I have a shared library node that calls DLL1 and another that calls DLL2  - When I do either option from Importing a Shared Library, if I select DLL1 in the wizard then DLL2 will no longer function (its path to the DLL does not change in the dialog box but it will not return a value). Similarlly, DLL2 will not work when using DLL1.

For this reason I avoid using the Shared Library tool at all because it seems to override some hidden setting.

I'd also like to note that this qualifies (i believe) as a bug if when I specify path on diagram for a shared DLL and THEN use import->shared library, the wizard will BREAK the CallFunctionNode that has its path hardwired.

Let me know if you cannot repeat this behavior - it is possible it appears inside a LVproject and some combination of LVRealtime.

[NoahR]

Hi Alex,

Would it be possible for you to post the code and the files that you are using to produce this issue?  I will be more than happy to look over it and try to reproduce your issue to see if we do need to report it to R&D as a bug.  Thanks and I hope to hear from you soon!

[AlexDubya]

Hi Noah,

I attended a local Users Group meeting and it would appear that this problem is caused by crosslinking issues that LV8.5's new project manager seems to solve. I do not have 8.5 at work yet but I suspect my problem will subside if we were to switch. I will repost here if I observe the errant behavior in the new version (whenever the comes about).

Thank you though for the excellent support.