Trouble with IMPORT SHARED LIBRARY wizard

[CoastalMaineBird]

LV2013, Win7

OK, my first venture into LabVIEW DLLs has not gone well.

I have a project where using ADDONs is (almost) the perfect solution.  You put the ADDON VI in a particular folder, and the host program can recognize them and load them into SubPanels, and they work.  Even if the host is compiled into EXE, the addons still load.

But there's a snag: If the ADDON uses CTLs or VIs from the main body, then it's subject to fragility - if the addon changes folder levels it can't find the pieces anymore.

They're not as robust as I would like.

So I thought I would try making the ADDON into a DLL.  I saw a post on this page <https://decibel.ni.com/content/docs/DOC-15556> that says "As long as what you're trying to do can be done in LabVIEW, you can do it in a LabVIEW-built DLL.".  So I tried it.

Making the DLL was easy.  Just create a build spec and go.

Then I tried using the CALL LIBRARY node, and couldn't figure out how to pass an LVRefNum (for a Notifier).  There is no such type in the CALL LIBRARY setup page.  I tried casting it to a U32.  It hangs the machine something fierce.

So, I don't know how to pass a Notifier Refnum to a DLL..

Then I discovered the IMPORT SHARED LIBRARY "wizard".  Why they call it a "wizard" when it's so blooming dumb is beyond me, but there it sits.

So, I tried it.  It complains that there are undefined symbols, and there is a header file not found: "extcode.h".

I wrestled with that and had no luck.

So... I backed up and tried a VERY simple VI: ADD.   Two numbers IN, one number OUT.

Again, making the DLL was easy.  

This time, making the CALL LIBRARY was easy.  It didn't complain about anything; it just works.

But the stupid "wizard" chokes again.

Here is what I see:

The first thing is: "No function is found and recognized in the header file".  Why not?   I don't know.

Then there's this:  "To correct this problem, check the header file to determine if you must add preprocessor definitions".

What does that mean?  There is the header file (in the pic above).  What is it about that header file would tell me that I need to add preprocessor definitions?  I don't know.

Then there's "Go Back to add a preprocessor definitionsl"   What's a "definitionsl"?  Why would I add one, and what would it be?

"For example, 'NIAPIstdcall = __stdcall".   Why would I add that?  I've no clue.

Then there's the weird word "_cplusplus".  Is it telling me that "_cplusplus" is the one it wants?  Well, WHY?  The header file includes an #IFDEF _cplusplus, so why is it needed?

If YOU (LV) generated the DLL, and YOU generated the header file, and YOU are importing the header file, then why the heck are YOU telling ME that I need to change it?

I tried putting those examples into the PreProcessor definitions fields, but nothing changes.

So, the next error is "The following header file was not found in the header file - extcode.h"  A file is not found in a file?  Lousy language, but I can figure it out.

I went and found the file in "C:\Program Files(x86)\National Instruments\LabVIEW 2013\cintools\extcode.h"

It says "To fix, go back and enter the header file path in the INCLUDE PATHS list".  So I did.  IT DOESN"T CARE.

Same message appears next time.

I triple checked the path to the file - it's correct.

It still complains that it can't find it.

I copied the CINTOOLS folder to the same folder as the DLL and pointed the path to it, but nothing changes.

If I copy the files ALL to the DLL folder, THEN it finds them.

But now I get MORE files not found, including "Carbon\Carbon.h".

REALLY?  To add two numbers in win7, it wants a header file from a 2001 OSX installation? ? ?

Obviously I am missing something.  THAT'S WHY I WANTED TO USE A WIZARD !.

Any clue as to what I'm missing?  

[Sam_Sharp]

If you're trying to load/run a VI dynamically, why not use the asynchronous call by reference node instead? When you want to extend that to loading from an addons folder then you can try using Packed Project Libraries instead?

(If the point of the exercise was to try building and calling LabVIEW DLLs then fine...I don't have too much experience of that so I can't help but I did want to point out that there might be a simpler way!)

[natasftw]

I haven't ran into this particular issue.  But, I generally avoid the wizard.  It works really well when it does.  But, that's not the typical experience from what I've seen.  When it doesn't, the solution is just to make the wrappers yourself.

I could see a potential reason why what you're doing wouldn't work well.  The idea of the import shared library is to bring in external DLLs and wrap up the call library node in a cute lil subVI you can drop wherever.  I understand you're trying to test things.  But, it's still a bit awkward to take lv code, turn it into a dll, wrap that dll call into a subVI, and go with that rather than just wrap it as a subVI to begin with. 

You'll likely be less frustrated if you make the wrappers yourself.  It's been a while since I've worked with the call library node.  Do you have a pointer data type you can use for the refnum?

[CoastalMaineBird]

If you're trying to load/run a VI dynamically, why not use the asynchronous call by reference node instead?

--- I can do that and it works just fine.  I run the addon and insert it into a subPanel and it's all good.

The trouble is the fragility.  If the user moves the addon to a different folder level, and if the addon uses controls / subVIs from the main host, then the loading process causes it to bring up the SEARCH box to try and find the pieces that aren't where it thought they were.

The host will be in an EXE, I don't know if the search even happens there.

I thought that maybe a DLL would encapsulate it - there would be a copy of the shared pieces within the DLL and I could move it around without linkage issues - the user just navigates to the DLL and goes.

When you want to extend that to loading from an addons folder then you can try using Packed Project Libraries instead?

--- I don't know what those are, or what they offer to this problem.

[Sam_Sharp]

For completeness - I've attached a sample solution showing different methods of loading/calling an 'Add' function using in LV2013 using packed project libraries. For my own learning/benefit I also had a go at creating a LV DLL from the code and then using the 'Import Shared Library' wizard - worked relatively painlessly for me for my trivial example!

Edit 1: Also - to answer your lvlibp (PPL/packed project library) question - a PPL is like a LabVIEW version of a DLL. It creates a single file (.lvlibp) from an lvlib and it contains the compiled code for that library. It also compiles in all of the dependencies needed by the library (like it does in an executable). You can open it like an llb in the development environment and add the VIs inside it to your block diagram in a compiled form (they are uneditable in an PPL) - if you take a look at my example then maybe it'll help to explain?

Edit 2: Because it compiles in all of the dependencies, you only need to know the path to the PPL and you can move/load the PPL from any location without breaking things.

[CoastalMaineBird]

 it's still a bit awkward to take lv code, turn it into a dll, wrap that dll call into a subVI, and go with that rather than just wrap it as a subVI to begin with. 

Well, I'm trying to get around the fragility problem.  It works fine now, where I call the addon by reference, and insert it into a SubPanel.  I have a message system to send it messages, including when to quit.   The controller window (VI) contains a resizable subPanel, which I fit to the addon, and offers a menu, and a way to show/hide the thing.

I can have any number of controller windows, with any number of addons, and it does exactly what I want

EXCEPT

If I move My Project\MyAddon.vi into My Project\MyAddonFolder\MyAddon.vi, then the next time I load the VI, it might complain, because it uses some control or subVI from main program and it's not where it was expected.

[Sam_Sharp]

I made a couple of edits to my post above.

I think unless you need to call your DLL from another language, you should probably go down the PPL route. It will support all LV data types (as long as your PPL functions have the same connector pane) and it handles the dependencies by pulling them inside the PPL like it does with an executable. It also saves having to configure the call library function node/use the wizard to create the wrappers.

[CoastalMaineBird]

I think unless you need to call your DLL from another language,

--- I don't.

you should probably go down the PPL route.

--- OK, I'm listening.  I'm also looking at your example.

It will support all LV data types (as long as your PPL functions have the same connector pane)

Well, i already have a "standard" ConnPane. Any addon with the wrong ConnPane produces an error for the user to deal with.

and it handles the dependencies by pulling them inside the PPL like it does with an executable.

QUESTION:  Does a PPL work OK with a LabVIEW EXE?  In other words, if the host is compiled into an EXE, can I plug in a PPL and have it work?

QUESTION: Can I have a COMPLICATED CALCULATION vi in the host, and have PPL#1 use it, and have PPL#2 use it, without conflicts?  (I assume that if I change the calculation, I would have to rebuild the host and the two PPLs).

QUESTION: If I move the PPL from PROJECT \ MYPPL.ppl to PROJECT \ SOME FOLDER \ MYPPL.ppl, without recompiling anything, and point the host to it , does it still work?

QUESTION:  Do ALL functions work across the fence?  Can I pass in a Notifier RefNum (as I do now) and then pass notifications and have them received in the PPL?

QUESTION:  Can the PPL have a user interface (visible panel)?

QUESTION: Can I insert such a beast into a SubPanel on the host, and have it work normally?

QUESTION: Can I obtain properties (such as FrontPanel.PanelBounds) from the main VI in a PPL?  I use that to size the containing window.

I plan to answer these by research, but if you already know the answer, then I'd appreciate your speaking up here.

[Hooovahh]

Thank you so much for taking the time to post this.  I've never had the Import Wizard work in a manor I would call "well".  And I don't think it could be more perfectly demonstrated than by trying to use a DLL made in LabVIEW.  If the import wizard works at all, I'd expect it to work with it's own DLL.

Even so I agree with the others, this doesn't sound like the right way to go about it.  Doing the DLL shuffle might work, but it seems unnecessary with other NI technologies like static VI references, and packed project libraries (which also have issues).

[CoastalMaineBird]

QUESTION: If I move the PPL from PROJECT \ MYPPL.ppl to PROJECT \ SOME FOLDER \ MYPPL.ppl, without recompiling anything, and point the host to it , does it still work?

the answer is YES!

This is the big hurdle. None of this answers why the wizard is such a turkey, but I don't care.