Xnodes - Find reference to vi in which an Xnode resides?

[gdog]

Hi,

Anybody know how to get a reference to the vi in which a particular Xnode resides, from within the Xnode? For instance, if I wanted to create a clean up wires routine which could be run by right clicking an Xnode and selecting it from the pop up menu.

Any help appreciated,

-G

[AdamRofer]

Hi,

Anybody know how to get a reference to the vi in which a particular Xnode resides, from within the Xnode? For instance, if I wanted to create a clean up wires routine which could be run by right clicking an Xnode and selecting it from the pop up menu.

Any help appreciated,

-G

If you need the information at run-time and not design-time, I recommend creating a Current VI's Path (refnode type=Function) or Call Chain (refnode type=Function) object.

However, I'm pretty sure you mean to use the information at design-time (node-run-time, what have you), so I did a little investigation.

I found out that extNodeRefNum.Owner.OwningVI returns a reference to the VI in question (I plugged .Name into a global which returned the 'dropped upon' VI's name). I don't know how often the system 'updates' the extNodeRefNum, but you know for sure it should work in the PropType@mods=1 step, where you probably could use the information the most.

- Adam

[gdog]

If you need the information at run-time and not design-time, I recommend creating a Current VI's Path (refnode type=Function) or Call Chain (refnode type=Function) object.

However, I'm pretty sure you mean to use the information at design-time (node-run-time, what have you), so I did a little investigation.

I found out that extNodeRefNum.Owner.OwningVI returns a reference to the VI in question (I plugged .Name into a global which returned the 'dropped upon' VI's name). I don't know how often the system 'updates' the extNodeRefNum, but you know for sure it should work in the PropType@mods=1 step, where you probably could use the information the most.

- Adam

Thanks,

I tried this in PropType@mods=1, and it works(lots of interesting stuff to play with, by the way). Then I tried to put it in Init@mods=0 and store the reference in a Global for later use. I observed, no effect where I dropped the Xnode. No Icon, nothing. But, the Xnode front panel displayed the running as subVi symbol. Okay, closed labview completely, switched it back to PropType@mods=0, no change. Deleted it completly from the Xnode, no change. It appears that putting extNodeRefNum.Owner.OwningVI into Init@mods=0 ruins the Xnode for good. Could something be getting stuck in the LV2 globals?

-G

[AdamRofer]

Thanks,

I tried this in PropType@mods=1, and it works(lots of interesting stuff to play with, by the way). Then I tried to put it in Init@mods=0 and store the reference in a Global for later use. I observed, no effect where I dropped the Xnode. No Icon, nothing. But, the Xnode front panel displayed the running as subVi symbol. Okay, closed labview completely, switched it back to PropType@mods=0, no change. Deleted it completly from the Xnode, no change. It appears that putting extNodeRefNum.Owner.OwningVI into Init@mods=0 ruins the Xnode for good. Could something be getting stuck in the LV2 globals?

-G

Well, I played around a bit more and saw that extNodeRefNum (typecasted to a string for visual aid) is incremented every event that fires, effectively ruining any 'preservation' of the refnum you desire. If you desire to play around with global reference, I would try writing to it each step (outside of the while loop) rather than assume it still points to the external node after x events fire.

Additionally, I see that in the Init step specifically, extNodeRefNum called with any property or method (not including getting a property that you don't use, LabVIEW apparently ignores this) causes the system to hang. It could be attempting to connect a reference to a block diagram object before it's technically created, causing my (and I assume your) system to hang, forcing a ctrl-alt-del to close LabVIEW (these nodes can easily hang your system if you call the wrong things).

The only solution to this I am able to find is to keep away from extNodeRefNum when it is in the Init step...PropType executes when you drop it on a diagram anyways, but be careful of the incrementing.

When I found out External Nodes, I always saw extNodeRefNum encapsulated in the PropTypes mods=1 step, so I see that as a subtle context hint from the developers. You should be fine outside of Init, however, as long as you compensate for the incrementing.

- Adam

edit:

p.s.: By "incrementing" I mean the refnum "value" is, for example: B160 001E, B170 001E, B180 001E for the three consecutive events that fire on drop. I assume that this means the older values do not refer to the External Node once a new one is created.

[Grampa_of_Oliva_n_Eden]

Y'all probably know this already but in this thread

http://forums.ni.com/ni/board/message?boar...=248768#M248768

an NI AE posted the attached llb that finds all shared variables in a project.

Ben