LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RemWireLooseEnds

Solved!
Go to solution

If you have this:

paul_cardinale_0-1697498527843.png

And you press Ctrl-B, you get this:

paul_cardinale_1-1697498558341.png

But if instead if pressing Ctrl-B, you execute paul_cardinale_2-1697498594126.png, you get this:

paul_cardinale_3-1697498623110.png

 

Gaaa!  I need to remove all broken wires (not just "loose" wires), but apparently such a method doesn't exist.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 15
(1,558 Views)
Solution
Accepted by paul_cardinale

Hi Paul,

 

Use this method instead:

raphschru_0-1697540093629.png

 

Regards,

Raphaël.

Message 2 of 15
(1,489 Views)

Be careful though.

 

If you use OwningVI to get from your diagram to a VI reference, you must close this VI reference!

 

OwningVI will create a new reference, and it will leak if you don't close it. It will as always close when the top level VI stops...

0 Kudos
Message 3 of 15
(1,448 Views)

wiebe@CARYA wrote:

Be careful though.

 

If you use OwningVI to get from your diagram to a VI reference, you must close this VI reference!

 

OwningVI will create a new reference, and it will leak if you don't close it. It will as always close when the top level VI stops...


I think the same is true for a reference to any object other than a GObject.

0 Kudos
Message 4 of 15
(1,427 Views)

@paul_a_cardinale wrote:

wiebe@CARYA wrote:

Be careful though.

 

If you use OwningVI to get from your diagram to a VI reference, you must close this VI reference!

 

OwningVI will create a new reference, and it will leak if you don't close it. It will as always close when the top level VI stops...


I think the same is true for a reference to any object other than a GObject.


Could be. But in the GObject hierarchy, there aren't that many (if any?) other than the OwningVI.

 

OwningVI seems especially easy to overlook. Maybe because it's the property of a GObject, and GObjects don't need to be closed.

0 Kudos
Message 5 of 15
(1,364 Views)

@paul_a_cardinale wrote:
I think the same is true for a reference to any object other than a GObject.

I would rather say any object other than a Generic.

0 Kudos
Message 6 of 15
(1,352 Views)

@raphschru wrote:

@paul_a_cardinale wrote:
I think the same is true for a reference to any object other than a GObject.

I would rather say any object other than a Generic.


Even if the object is an integer? Close the integer?

0 Kudos
Message 7 of 15
(1,340 Views)

wiebe@CARYA wrote:

@raphschru wrote:

@paul_a_cardinale wrote:
I think the same is true for a reference to any object other than a GObject.

I would rather say any object other than a Generic.


Even if the object is an integer? Close the integer?


Well, we were implicitly talking about VI Server references of course.

So any VI Server reference which does not belong to the Generic hierarchy must be closed.

References that belong to the Generic hierarchy do not need to be closed.

0 Kudos
Message 8 of 15
(1,319 Views)

@raphschru wrote:

wiebe@CARYA wrote:

@raphschru wrote:

@paul_a_cardinale wrote:
I think the same is true for a reference to any object other than a GObject.

I would rather say any object other than a Generic.


Even if the object is an integer? Close the integer?


Well, we were implicitly talking about VI Server references of course.

So any VI Server reference which does not belong to the Generic hierarchy must be closed.

References that belong to the Generic hierarchy do not need to be closed.


But then it's just what Paul said?


@paul_a_cardinale wrote:
I think the same is true for a reference to any object other than a GObject.

 

0 Kudos
Message 9 of 15
(1,307 Views)

"Generic" and "GObject" are not the same, the first is the parent class of the second:

 

raphschru_0-1697636925370.png

 

I just said his affirmation can be applied to one level higher in the VI Server hierarchy.

Message 10 of 15
(1,296 Views)