LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RemWireLooseEnds

Solved!
Go to solution

@raphschru wrote:

"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.


Fair enough.

 

The removal of the word 'reference' threw me off there.

 

I'd combine the two:

"The same is true for a reference to any object other than a Generic."

0 Kudos
Message 11 of 15
(534 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.


Are you sure?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 12 of 15
(515 Views)

Well, the documentation here says:

 

"You do not have to close the following types of references since leaving them open does not impact performance:

  • References that inherit from GObject
  • This VI or This Application static references"

 

 

But another documentation here says:

 

"Closing VI References that Have Child Object References

 

… closing the parent VI reference automatically closes child object references of that VI.

 

… In the following example, if you close the VI reference immediately after LabVIEW opens the VI reference, the front panel reference may become invalid before LabVIEW can get the class name.

 

… In the previous example, you do not need to close the front panel reference because the front panel reference closes when you close the VI reference."

 

 

So the 1st document states explicitly that GObject references do not need to be closed.

But to me, the 2nd document implies that this is true for all Generic references. Indeed Generics are all child elements of a VI. Since they gave the example of the Front Panel and said it does not need to be closed, I assume it is the case for all Generic references.

 

As a side note, I think Generics are actually the child objects of a VI and GObjects are those which are graphical. So non-GObject Generics are abstract child objects that are "too abstract" to be graphical (i.e. they have no position, bounds, ...).

 

All non-GObject Generic references that I have tested are closed when the VI leaves memory (ConnectorPane, Cursor, FlatSequenceFrame, TimeSequenceFrame, Page, Plot). For the rest I have no idea how to test because I couldn't figure out how to get a ref of those types (Bus, MasterWizard, Probe, SubWizard).

 

Here is my benchmark if you want to test it.

0 Kudos
Message 13 of 15
(502 Views)

@raphschru wrote:

Well, the documentation here says:

 

"You do not have to close the following types of references since leaving them open does not impact performance:

  • References that inherit from GObject
  • This VI or This Application static references"

 

 

But another documentation here says:

 

"Closing VI References that Have Child Object References

 

… closing the parent VI reference automatically closes child object references of that VI.

 

… In the following example, if you close the VI reference immediately after LabVIEW opens the VI reference, the front panel reference may become invalid before LabVIEW can get the class name.

 

… In the previous example, you do not need to close the front panel reference because the front panel reference closes when you close the VI reference."

 

 

So the 1st document states explicitly that GObject references do not need to be closed.

But to me, the 2nd document implies that this is true for all Generic references. Indeed Generics are all child elements of a VI. Since they gave the example of the Front Panel and said it does not need to be closed, I assume it is the case for all Generic references.

 

That argument is invalid because a Front Panel is a GObject.

 

 

As a side note, I think Generics are actually the child objects of a VI and GObjects are those which are graphical. So non-GObject Generics are abstract child objects that are "too abstract" to be graphical (i.e. they have no position, bounds, ...).

 

All non-GObject Generic references that I have tested are closed when the VI leaves memory (ConnectorPane, Cursor, FlatSequenceFrame, TimeSequenceFrame, Page, Plot). For the rest I have no idea how to test because I couldn't figure out how to get a ref of those types (Bus, MasterWizard, Probe, SubWizard).

So the answer is 'No', you are not sure.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 14 of 15
(491 Views)

@raphschru wrote:

All non-GObject Generic references that I have tested are closed when the VI leaves memory (ConnectorPane, Cursor, FlatSequenceFrame, TimeSequenceFrame, Page, Plot).


The VI leaving memory is just something that happens when all references to the VI are closed...

 

If references are closed when the VI leaves memory isn't relevant to the question if we need to close references.

 

The real question is: Are all generic references static? Iff (if and only if) a reference is static, it doesn't need to be closed.

 

wiebeCARYA_0-1697706523843.png

 

This returns 2X true, because the panel (a GObject) of a VI is a static reference. The returned reference of the panel is always the exact same binary reference, as long as the VI stays in memory: it's a static reference. So it doesn't need to be closed.

 

It doesn't need to be closed, because it wasn't created by obtaining the reference. It is created when the VI was created, and it is closed when the VI leaves memory.

 

Of course a clone of a VI counts as a new VI, with it's own references. GObjects for sure. Generics maybe.

0 Kudos
Message 15 of 15
(471 Views)