Labview project executable activex server with excel vba client

[Alex1.618]

Hello all,

I've submitted a ticket to ni support about this problem, but my deadline for this project is nigh, so I'd like to poll the community to see if anyone has encountered this problem before (I hope it's ok that I'm doing this!). I've done a fair amount of forum-scouring, and I haven't seen this problem discussed yet.

I have built a labView project that in essence takes in data from hardware and 
preforms various visualizations and transformations on the data. A few of the 
VIs in this project are accessed by Excel VBA, using LabView as an ActiveX server and 
Excel as the client--and it works! I recently found out I would need to make an 
executable version of my project, so I'm now trying to figure out how to do the same thing 
with my executable as the server instead of LabView. Here's a pared down version of 
my VBA code:

Sub Button1_Click()
    Dim lvapp As MyServer.Application
    Dim vi As MyServer.VirtualInstrument

    Set lvapp = CreateObject("MyServer.Application")
    
    Set vi = lvapp.GetVIReference("Main.vi", "", True)
    
    Sheet1.Cells(1, 1) = vi.GetControlValue("Path")
    
    lvapp.Quit
End Sub

I replaced LabView here with the name of my server. The code 
fails on the CreateObject method with the following error:

Run-time error '13':
Type mismatch

Things I'm fairly sure I'm doing correctly:
-The application is configured as an ActiveX server in build options
-I run the VI once and close/reopen it right after each build before trying the 
spreadsheet
-The in excel, the VBA method is set up to Reference the server's type library.
-I have LabView itself closed when I run the .exe


Thank you,

Alex

My versions and such:
NI Software :  LabVIEW  version 2012
OS :  Windows 7

[Burrito]

This error might occur if a LVClass or any dynamic VIs of a LVClass are in the Always Included section of the Source Files tab in the Build Specifications window. Try removing all LVClasses and all dynamic VIs of any LVClass from this section if you have any. 

[Alex1.618 · Accepted solution]

That's interesting--I'll have to look into that. In the meantime, I have found a fix.

It is rather mysterious, but it seems that all I had to do was make sure only the executable server's type library was referenced in VBA ( not LabView or OLE type libraries), and declare the app variable as Object rather than MyServerName.Application. Honestly, I have no idea why this works, but it does. Also, I found out you need to use the executable file paths, which are a little different than the project file paths.

Thank you,

Alex

[Dave_Karon]

Now I'm having the same kind of problem.

An Excel VBA code I've been using for years with Win2K and O2K, and several executables with ActiveX servers built in LV 5.1.1, 6.1, and 8.0.

My Spreadsheet's VBA code launches the LV executables and then gets data from front panel objects (indicators).

Now trying to get the same running under Win7 with Excel 2010 with no success.

I can instantiate one of the VIs built in LV 8.6.1, but the others don't cooperate.  Always get the "error 429 can't create object".

I've tried creating the LabVIEW executables in 8.5.1, 8.6.1, and LV 2011 SP1.

I've also tried declaring as object ("DIM myApp as Object").  That didn't seem to help.

Tried using "SET myApp = NEW myLVApp.Application" and "SET myApp = CreateObject("myLVApp.Application")".

Thanks,

Dave

[TBirkulosis]

Error 429 is an ActiveX error. If you run the application as an administrator (right-click >> Run as Administrator), can you successfully create the object? Also, when you build the application, make sure to enable the ActiveX server for the application. To do so, place a checkmark in the Enable ActiveX server checkbox on the Advanced page of the Application Properties dialog box, as discussed in the LabVIEW 2013 Help Manual.

[Dave_Karon]

Taylor, 

I had a service request in for this issue and the assigned engineer found some helpful additional references, particularly:

http://digital.ni.com/public.nsf/allkb/C273D9584B1B150286256DDA00510A73?OpenDocument

With Windows 7, I found that there were some not-too-well documented security features that affected me.

1) it seems each user account has to register each ActiveX server, in order to be able to communicate with it. 

2) The user has to have administrator privileges to be able to register the server. 

Thanks

Dave

[TBirkulosis]

Dave,

Thanks for letting me know this information. It's always helpful to post solutions to the forum in case others run into this issue. I'm glad to hear your application is working.