11-16-2012 04:12 PM
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
Solved! Go to Solution.
11-19-2012 05:49 PM
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.
11-20-2012 07:41 AM
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
05-05-2014 01:23 PM
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
05-06-2014 09:46 AM
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.
05-06-2014 09:54 AM
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
05-06-2014 10:03 AM - edited 05-06-2014 10:03 AM
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.