ni.com is currently undergoing scheduled maintenance.

Some services may be unavailable at this time. Please contact us for help or try again later.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 97 using Active-X property node

I created a very simple VI. I put an Active-X container on the FP and inserted an Active-X object. On the BD I created a Property node with the property Filename. I wired a constant with a file path to it. Runing the VI the property node gives me Error 97 Unknown system error.

If I use the Property Browser I can see the property Filename. If I enter the same path there the object will be updated.

The question is why can I set the property through the property browser and why I get an error doing it with LV?

I do not have any further information bout the Active-X control. It is part of an application I have bought and I have seen that other tools around this application use this control too.

This problem occurs in 7.1.1 and 8.0
Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Message 1 of 13
(13,424 Views)

Can you post a test VI along with the ActiveX control? 

-Khalid

0 Kudos
Message 2 of 13
(13,390 Views)
If the ActiveX control came from a purchased program then posting it would not be legal unless the publisher of the program allows the ActiveX control to be distributed.

Have you tried using the Automation functions rather than an ActiveX container?
0 Kudos
Message 3 of 13
(13,381 Views)
It will be problematic to distribute the OCX file here.

I have included 3 screen shots to show you what I see. Start.png shows the state when I load the VI. The error cluster is empty. Programmatic.png shows the state after the vi was run. At this time the error cluster contains error 97. After that I copied the string from the BD to the Property browser. PropBrowser.png shows this state and you can see that the OCX will be updated and showing a 3D-model.

My problem is why does the Property Browser work and the Property Node not.
Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Download All
0 Kudos
Message 4 of 13
(13,375 Views)
I have to ask a dumb question. Based on the pictures, why aren't you wiring the control's terminal to the Property node? It looks like you're wiring some other reference. In fact, it looks like you've placed an ActiveX Reference object on the block diagram that's independent of the front panel control. Not sure why you did this. Just wire the control to the Property node.
Message 5 of 13
(13,374 Views)
Because I'm dump in Active-X controls. I did some work in Active-X automation. I keep out platform specific code as much as I can because we plan to serve the Linux platform in near future.

First I tried to do it like I would do with LV controls just place the property node on the BD and link to the control and it works. This caused the VI not to be executable. It complained about a missing input on a terminal of the property node. Since the property node was created from the container with the OCX already placed I thought creating a constant would contain the correct reference.

smercurio... your answer was absolutly correct.
Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
0 Kudos
Message 6 of 13
(13,368 Views)
No problem. Glad it was a simple fix.

I think I understand what may have happened when you were trying it. When you placed the ActiveX container on the front panel and selected the ActiveX control for it, you got a control that was basically a reference to an ActiveX object. When you right-click the control and select "Create Property Node" you're creating a LabVIEW control property node that's linked to the LabVIEW control, and not an ActiveX property node that's linked to the ActiveX control that's inside the container. In fact, even if you place an ActiveX property node on the block diagram from the Functions>>Communications>>ActiveX palette and then right-click on it and select the front panel control it will change the property node type to a LabVIEW control property node. Kind of annoying, but it's the right thing to do.

When you placed the constant on the block diagram you were specifying a reference to "an" ActiveX class, not a reference to "the" ActiveX class that you had on the front panel. With the constant you would need to use the "Automation Open" but if you did that you would probably get error 3005 which basically tells you that you can't instantiate the class this way.

Anyway, hope that doesn't make things more confusing for you.

By the way, make sure you close your references after you're done with them, including references that get automatically generated if you're accessing properties of the control that return another class. LabVIEW has been known to crash if ActiveX references are left open and you quit out when you're done. Believe me, I know.
Message 7 of 13
(13,360 Views)
Waldemar,

What you started to do in the first place is what you really want to do.
You right-clicked the container node on the BD and picked "Create >> Property".
It created a property node for the control inside the container. Unfortunately,
when the node is dropped, for some silly reason it is not automatically linked
to the control, so you do have to manually wire it to the container.
That's why LV complained about the unwired input.

You may have thought that you shouldn't have to wire that input terminal if you
have had experience with linked property nodes. For example, if you right-click the
container node on the BD and pick "Create >> Property Node" instead of
"Create >> Property" [yes, the similarity of the names is very unfortunate],
then you'll get a property node for the LV Server object that represents the
container itself. The node that is dropped is implicitly linked to the container,
so it doesn't need to be wired to it. It has a different and more compact appearance.

You can change a linked property or invoke node to an unlinked one by right-clicking
and choosnig "Disconnect From Control."
You can change an unlinked property or invoke node to a linked one by right-clicking
and choosing "Link to >> <name of control>".

I think
smercurio's description of getting a distinct instance of the control when you placed
the control on the BD is correct. He also may have been confused by "Create>>Property Node"
vs. "Create>>Property".

Also, never close the reference to the control that's in a container because the container
is always going to close if for you when the VI shuts down. Closing does a COM Release
call, so you end up crashing or at least getting a nasty exception when you try to release
an object that has already been destroyed.
George Erwin-Grotsky
National Instruments
LabVIEW Research & Development
0 Kudos
Message 8 of 13
(13,348 Views)
No, I wasn't confused - I was refererring to the menu options when right-clicking on the front panel. There is no "Create>>Property" menu option when you click the container object on the front panel. That only appears when you right-click on the block diagram. At least that's the case in LV7. Haven't checked in LV8.

You are correct with respect to not closing the reference to the control itself. MIssed that point. Thanks for spotting it.
0 Kudos
Message 9 of 13
(13,341 Views)
[Correction to my prior post. I'm learning new stuff here and thought I understood it better than I did.]

While you can generally convert implicitly linked property and invoke nodes to explicitly linked nodes (what I was calling linked and unlinked, respectively), LabVIEW does not currently support implicitly linked nodes for the control within an ActiveX or .NET container. That's what smercurio was talking about, but I didn't quite understand when I read that post (03-08-2006 05:05 PM)..

George Erwin-Grotsky
National Instruments
LabVIEW Research & Development
0 Kudos
Message 10 of 13
(13,339 Views)