Accesing COM child object

[FJ_Sanchez]

Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 

Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

 

[Rolf Kalbermatter]

Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 

Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

Well, the code you claim causes problems in LabVIEW is commented out in the VBA code. So are you sure it does anything else in VBA than in LabVIEW if you enable the code?

[FJ_Sanchez]

Hi, it's not commented out in VBA, it's just wrong syntax highlight. I think I'm doing exactly the same, but something should be wrong or I would get same result.

[Mark Smith]

Looks to me like you close the ref to SMAOMain in parallel with the loop you use to try collect the Enabled Drivers info. Once you close that ref, your SMAOMain object gets cleaned up and you're likely looping on a closed ref to the SMAOMain.info property when you try to get the enabled drivers.

 

Mark

[Rolf Kalbermatter]

Looks to me like you close the ref to SMAOMain in parallel with the loop you use to try collect the Enabled Drivers info. Once you close that ref, your SMAOMain object gets cleaned up and you're likely looping on a closed ref to the SMAOMain.info property when you try to get the enabled drivers.

 

Mark

 

Shouldn't really happen, since the error cluster is wired through (at least it looks like it is, didn't check in the actual code).

[Mark Smith]

Rolf,

 

On the attached picture, the ref wire from the _SmaoMain property node used to get the ref to the SmaoMain.Info property goes around the While loop where the Enabled Devices get queried  and into a Close Ref. There's no data dependency I see that would keep the Close from operating on the Initialized _SmaoMain object before the property of that object gets queried. If the object that contains the property data gets closed, wouldn't the data associated with that property likely get disposed as well? Am I missing something obvious?

 

Mark

[Rolf Kalbermatter]

Rolf,

 

On the attached picture, the ref wire from the _SmaoMain property node used to get the ref to the SmaoMain.Info property goes around the While loop where the Enabled Devices get queried  and into a Close Ref. There's no data dependency I see that would keep the Close from operating on the Initialized _SmaoMain object before the property of that object gets queried. If the object that contains the property data gets closed, wouldn't the data associated with that property likely get disposed as well? Am I missing something obvious?

 

Mark

 

 

The ref num goes around the loop but the error cluster goes through the loop and then to the two Close Refnum nodes. At least that is how it looks in the picture. Maybe the real wiring is behind the loop but that would be a major style fault. Unfortunately the VI Snippet resource seems to get lost between posting to LAVA and downloading it to my computer, so can't really check it.

[Mark Smith]

OK - I see what you see and concur - it shouldn't get closed before the loop exits. I'll blame it on old age and bad eyesight

[FJ_Sanchez]

After some time trying still stuck with this, even NI support couldn't give me a solution, probably the COM object isn't fully ActiveX compliant or compatible with LabVIEW implementation of ActiveX... I'm going to make a wrapper DLL in C++ that handles the COM calls and pass data into LabVIEW, but I've never done it before and I'm struggling to make it work.

[Mark Smith]

We've had reasonable luck using hard to call from LabVIEW COM implementations by wrapping them in .NET and then calling the .NET DLL/Assembly. It's pretty quick to create the .NET wrapper and try it and it may just work.

 

See this link for details http://msdn.microsoft.com/en-us/library/ms404285.aspx

 

Mark

[FJ_Sanchez]

Hello,

 

finally I got the solution to my problem but I didn't post it here, so I do now to help anyone that could encounter this problem. I'm not sure if the COM object is non-thread safe, but the fact is that if I mark the VI to run in UI thread everything goes smooth...

 

Regards.

[Rolf Kalbermatter]

Hello,

 

finally I got the solution to my problem but I didn't post it here, so I do now to help anyone that could encounter this problem. I'm not sure if the COM object is non-thread safe, but the fact is that if I mark the VI to run in UI thread everything goes smooth...

 

Regards.

 

Well the COM automation server should have been installed with a setting that specifies what threading model it is happy with. LabVIEW honors that setting. The common threading models that are available in COM would be:

 

- single threading, this component can only be called from the main thread of the application that loaded the component. The LabVIEW UI thread coincidentally also is its main thread.

- apartment threading, this component can be called from any thread but during the lifetime of any object it must be always the same thread

- free threading, the component is fully threading safe and can be called from any thread at any time in any combination

 

Most Automation servers require apartment threading, often not so much because it is required than simply because it is the default and many developers are to lazy to verify if their component would run with a less restrictive threading and more serious, if their component might actually require a more restrictive threading model.

[Rahul A. Kharche]

On 1/22/2014 at 4:04 PM, FJ_Sanchez said:

Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 

Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

 

can you please upload this library and vis