Open VI Reference Error when Using a LV Created EXE as ActiveX Server

[thutch79]

Making a long story short, I'm trying to create an executable in Labview that I can call from another Labview program via active x. I've been using the following article as my guide:

https://decibel.ni.com/content/docs/DOC-9647

It seems simple but I keep getting error 6945 saying that the VI name is no longer suffiencient. I've checked and rechecked the VI name that feeds VI path and I know it is correct. All I'm really trying to do is grab the VI reference so I can hide the front panel. Attached is a screenshot of the code and the error. Any thoughts?

[TailOfGon]

Is your "Hamilton Control Server.vi" owned by a library (lvlib) or a class (lvclass)?

[thutch79]

No it's not. It should be just at the root of the executable. It's the startup vi of the executable.

[TailOfGon · Accepted solution]

I would first try to run the executable and get the VI path by including "Current VI's Path" primitive in the VI. This is to make sure your calling path really matches what is in the executable.

[NEWKlear]

Thutch,

TailofGon realy hit this one on the head.  Once we have that information we will better be able to help you with your issue.

Regards,

[thutch79]

I feel stupid now. I don't know why I didn't try that before. I've even done that same thing in the past. It was buried in folders I didn't expect. I'll have to go though the build spec and see why.

I did, however, find a better solution. What I'm trying to do in the long run was create a background process. This seems to be a much better solution.

http://digital.ni.com/public.nsf/allkb/EFEAE56A94A007D586256EF3006E258B

[TailOfGon]

Glad it worked. I am curious as to why there was additional folders. From my experience, I know a vi gets kicked out of the executable into a folder next to exe if there is a name collision between classes (lv86). But never seen a folder created within exe, maybe it's a feature of newer version of LabVIEW ?

[dbell0971]

Hi all,

Tail, you are correct, this was changed in LabVIEW 2009.  This link has a description of changes made in LabVIEW 2009; the name conflict within applications is addressed about halfway down.

http://zone.ni.com/reference/en-XX/help/371361F-01/lvupgrade/labview_features/

Thanks,

David B

[TailOfGon]

Thanks, dbell

This is such an awaited improvement and I am shocked that I did not know about it until now. I want to move to LV 2009 or later so that I do not have to expose bunch of VIs outside of executables. In LV8.6 if you use inheritance of LV Classes then conflicting name was inevitable as overriden VIs always have the same name as the parent method VIs (prefix does not fix it).

And I guess we need to add some comments on this page from PO  >> https://decibel.ni.com/content/docs/DOC-9647

[dbell0971]

Thanks for the comment and notes Tail, updating these really helps all users of LabVIEW.  I'm glad that this helped you out; I'm sorry that the information didn't get disseminated to you sooner.  Hope it helps.

Thanks,

David B