Trouble with IMPORT SHARED LIBRARY wizard

[CoastalMaineBird]

The wizard isn't a "turkey," you're expecting it to do the impossible.

You mean it's impossible for LV to create a DLL and then have LV turn around and import that same DLL?

Well, I can do it on the simple case (C=A+B), with a simple CALL LIBRARY node.  

But the "wizard" can't do it without a seemingly endless stream of ugly hacks.

So, maybe it is impossible.

[CoastalMaineBird]

I suspect you can get the notifiers to work by typecasting to a U32, but it would be dangerous.

No.   As I said earlier, I tried that and it hangs the machine. 

[nathand]

---

@CoastalMaineBird wrote:

The wizard isn't a "turkey," you're expecting it to do the impossible.

You mean it's impossible for LV to create a DLL and then have LV turn around and import that same DLL?

Well, I can do it on the simple case (C=A+B), with a simple CALL LIBRARY node.  

But the "wizard" can't do it without a seemingly endless stream of ugly hacks.

So, maybe it is impossible.

---

Well, again, the issue is that you as the programmer have more information than the header file provides. You know that A and B are 32-bit integers, so you can easily configure the Call Library node appropriately. C has no standardized way to specify an integer of a certain number of bits, so the DLL Builder has to go through some hacks to force the C compiler (assuming you're calling it from C) to use an integer of the correct size, and those hacks become challenges for the DLL import wizard. Yes, NI could possibly modify the import wizard so that it recognized LabVIEW-specific data types, but what would be the point? While I know people do build LabVIEW VIs into DLLs and then call them from LabVIEW all the time, there's a good argument that that's the least-useful situation for the import wizard because you shouldn't need to do this. The root of the problem is the intentionally-vague C standard, but ignoring that, it's equally reasonable to blame the DLL builder instead of the import wizard.

[nathand]

---

@CoastalMaineBird wrote:

I suspect you can get the notifiers to work by typecasting to a U32, but it would be dangerous.

No.   As I said earlier, I tried that and it hangs the machine. 

---

I'd be curious to see this code (preferably a snippet as I'm still on LabVIEW 2012). Where does it hang? At the Type Cast to the U32, or when you typecast back to a notifier, or somewhere else? Slight possibility you need to typecast to a 64-bit value, not a 32-bit one; you could check by typecasting to both and seeing whether the values differ. Also could be an endianness issue at the DLL call, if you aren't careful.

[CoastalMaineBird]

Well, that was the point where I chucked out that project and said "I need to make it work on a simpler VI first".  I don't have that code handy.

It hangs on the call to the DLL.  I'm in LV2013-32, so it's unlikely that the LV RefNum was a 64-bit thing.

And since I couldn't even get the C=A+B thing to work, either, the whole line of pursuit is a bust.

This needs to work where my customer can develop addons. While he's fair at LabVIEW, I don't want him to deal with all this "C" crap.

[nathand]

---

CoastalMaineBird wrote:  

While he's fair at LabVIEW, I don't want him to deal with all this "C" crap.

---

Isn't that why people often choose LabVIEW? 😉

For the A+B thing though - if you do want to make the import wizard work, a few quick edits to the header file would do it. Remove the reference to extcode.h, and replace int_32t with int. If you didn't want to do that, you could instead provide a much-reduced extcode.h that simply defined int32_t to int (and whatever other types are needed), and supply that with the unmodified header built by the DLL builder. I haven't tried this second approach, but I suspect it would work.

Not that you're going that route, but maybe it's helpful to someone else in a similar situation.

[Sam_Sharp]

I used the Import Shared Library Wizard to create the wrapper for my Add DLL in my example. I'd never used it before but I managed to successfully create the wrapper VI without too many troubles.

[CoastalMaineBird]

What version LabView?

[Sam_Sharp]

2013 - same as the example I gave (which is where I tried it).

Building the DLL:

Importing:

Include paths and preprocessor definitions were left blank.

[CoastalMaineBird]

Well, it's academic at this point, but I do wonder why.

Is your header different from mine (shown in the pic above)?

Did your header include a request for EXTCODE.h?

If so, where did it find it?

Did you have to point out the path yourself?

Like I said, it's academic, so ignore if you're not in academic mode.