Problem in calling C# dll

[Alkid]

Hello:

I am trying to integrated the function developed by Labview(2009) and exported as dll library. It is called by C#, but run into some problem

file not found, throud lib excel open

as I call the function by C#, it returned with error code 7,

as i call this function, it returned 0.

Is there a way to find out the difference and fixed it?

here i attach the test lib.

[wiebe@CARYA]

Code 7 is "file not found".

Note that C# will probably see \'s in the path as an escape code. Put a popup in the VI to see what you're trying to open.

[Alkid]

in C# here the file name:

     ss.FileName = "D:\\customer\\BYD\\123.xls"

and the source array pass into the dll

source path array:

With the 2nd test example, file exist, it reports the file is found. But for the 1st function, it is reported as not found.
is there other possible situation causing the error?

[wiebe@CARYA]

The binary value of the string isn't relevant (well, it is, but it is indirect).

Add a popup to the VI, to see what the LabVIEW string look likes. "D:\\customer\\BYD\\123.xls" might  just as well turn up as valid directory path in LV ("D:"?). This directory might exist, so you won't get an error. Should take you <5 minutes to know this for sure.

Another idea. Add the file info function to the first example. Does it work in there as well? This should make clear if the problem is in calling the examples...

Does the first examples work in normal LV?

[Alkid]

the files in the attached is workable in LV.

Within the functions in the dll library, it pup up an dialog, but not thing there and program hangup.

i have no idea to check what the message path it received.

But for the 2nd example, file exist check, it passes.

I pass the same value to example1 and 2 by checking the return code.

In example 1, it calls the function "New Report.VI" in "NIReport.lib" with excel type

and the error code 7 is returned from it.

[wiebe@CARYA · Accepted solution]

Ah. I think I've got the problem.

The New Report vi tries to dynamically load the Excel class. It does this by path. But this class is not available in the dll context.

You need to find a way to include the Excel class. If you open New Report.vi, you'll see what happens. The Excel path VI returns this (on my PC):

\vi.lib\Utility\NIReport.llb\Excel\NI_Excel.lvclass

This class has a VI "New report subVI.vi". If you use that one instead of New Report.vi, it might just turn out well.

[Alkid]

yes. exactly it is a problem and be

---

 

The New Report vi tries to dynamically load the Excel class. It does this by path. But this class is not available in the dll context.

You need to find a way to include the Excel class. If you open New Report.vi, you'll see what happens. The Excel path VI returns this (on my PC):

\vi.lib\Utility\NIReport.llb\Excel\NI_Excel.lvclass

This class has a VI "New report subVI.vi". If you use that one instead of New Report.vi, it might just turn out well.

---

And I can not fully understand what happened with the dynamic feature.

As tracking the block diagram of "New report subvi.vi", the path is directly pass into a sub diagram to check if the file exist or not. Unfortunately it fails.

I copy it into the block "FileExist.vi" and test, it works.

Thank you and it works to using excel lib directly.

[wiebe@CARYA]

New Report.vi tries to dynamically load the NI Excel.lvclass. This works in development environment, since the entire vi.lib is in it's search path. So running\debugging in dev.env. works fine. But the class won't load well in the executable (a .dll is a special kind of executable). It might find NI Excel.lvclass, but even if that's the case, some of it's subVI's won't be available in the executable. So avoiding the dynamic loading seems the best solution.

Normally, the programmer is aware of the dynamic loading, but in this case it's hidden in a "normal" function. Since it's not expected, it took long to identify the problem...

[rolfk]

The proper way to solve this is to include somewhere a dummy VI that is never called in your code (a case structure whose select terminal is wired to a hidden boolean control on the front panel, and yes it needs to be a control, a constant won't work as LabVIEW will recognize that this code can be eliminated without any detectable side effects in runtime behaviour and remove the code in the built application anyways, if you use a boolean diagram constant).

This dummy VI needs to reference one of the public methods or the class constant of the dynamic class you want to have available in your executable. That is how I usually do this. Another option is to add the class as a Always included reference to the build configuration, but I only have done that with dynamically called VIs, never with classes so not quite sure about the possible caveats in respect to classes.

[wiebe@CARYA]

Just a class constant on the diagram will force the class to be included in the executable.