Showing results for 
Search instead for 
Did you mean: 

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

Go to solution

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:


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?

0 Kudos
Message 1 of 10

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

Certified LabVIEW Architect 2013
0 Kudos
Message 2 of 10
No it's not. It should be just at the root of the executable. It's the startup vi of the executable.
0 Kudos
Message 3 of 10
Accepted by thutch79

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.

Certified LabVIEW Architect 2013
Message 4 of 10



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




J Newk
Systems Engineer
National Instruments
0 Kudos
Message 5 of 10

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.


0 Kudos
Message 6 of 10
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 ?
Certified LabVIEW Architect 2013
0 Kudos
Message 7 of 10

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.





David B

Message 8 of 10

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  >>

Certified LabVIEW Architect 2013
0 Kudos
Message 9 of 10

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.




David B

0 Kudos
Message 10 of 10