I'm sure I'm doing something really silly but.....

[Intaris]

Well, U32 doesn't change anything.

I'm still at a loss as to why this is happening.  Perhaps it IS the different types.... Someone from NI care to offer an enlightened opinion?

Shane.

[Ray.R]

Hey Shane,

The joys of CVI...  🙂

Are you following in my footsteps?  😉  

(coding in C / CVI)

[Intaris]

If your footsteps lead to a solution to my problem, GLADLY!

I'm going to file a bug report because I have no idea why this DLL call isn't working.

Shane.

PS BTW, whenever my code DOES try to open a reference to a USB device, LV claims there was an error in calling the DLL but the Driver Package LibUSB claims there was no error.  Anyone know where these mysterious errors could be coming from (Opaque data type usb_dev_handle perhaps) and could THEY be the reason for a default NULL return value?

Message Edited by Intaris on 10-30-2009 11:57 AM

[jr_2005]

Can you try building a skeleton CVI program which makes similar calls into the dll, just to see if it is the dll or the LabView calling framework that is causing the problem?

JR

[Intaris]

That's a good idea.

No wonder I didn't come up with it.... 

Thx.  Is on my to-do list for today.

Shane

[Intaris]

Does wiriting a program to include the *.lib and *.h files of my DLL count or should I be loading it dynamically?

If I include these files, it seems to work.

Shane.

[Intaris]

BTW, are there no Cluster (struct) items for the UI?

Shane.

[jr_2005]

For most programs, it is the normal approach to include the .h and .lib files within a CVI project that will use a dll. The .lib import library file in this case is effectively a stub, which loads the dll's functions at runtime without the programmer needing to know what is going on under the hood. Loading dll files dynamically gives more control over paths, versions and error handling, if a particular project demands that kind of stuff.

So you can get a CVI program to call your dll OK? See what can be achieved in a proper coding environment

I'm not familiar with LabView clusters - if these are comparable to the C's struct then no, this is not handled directly by a CVI UI object. Most programmers would simply define the struct in a header file and then just use instances of them as variables within the C code. Individual struct components (such as ints, doubles) could then be handled by the appropriate standard UI controls, if required.

JR

[Intaris]

Ah, in LV we can just create a control on the UI of any arbitrary data structure (for debugging - and every code module has its own UI in LabVIEW - again great for debugging) - see what's possible in a proper coding environment?

Well if that's the normal way to do things, then my DLL itself seems to be working just fine. I'll give LabVIEW another shot before filing a bug report on LVs handling of my DLL.

I'm getting the same value back as the dialog within the DLL is showing.  The problem seems to be the transfer of the value from the DLL to LabVIEW then.  At least I know ehere to look now.

Thanks.

Shane.

[Intaris · Accepted solution]

Hmm,

It seems to be working now (for the moment at least).

In order to be able to use my DLL in CVI I had to re-compile it as __cdecl instead of __stdcall.

Apparently CVI can only use __cdecl DLLs?  Is this correct?

After making this change and changing the DLL call in LV appropriately, it suddenly started working.....

I'm even more confused than before but I'm happy that it seems to be working.

I hope it stays that way.

Shane.