LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Intaris

Static reference for "This Diagram" (like "This VI")

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.

I am currently trying to do something which is apparently impossible.

 

I want to create some code which returns a string which represents the selector of an event structure in which the code is executing.  Obviously, scripting is required for this.  While I can do this if the VI I am using for the task is used in only one event structure case (traverse for items) it doesn't work with a cloned VI.  The sub-VI reference found returns the VI definition of the non-cloned instance.  As such there is no way to actually find a specific clone.

 

The key here is that I want to have access to the "Diagram" of the event structure where the code is executing. If I would be able to drop a scripting type constant "This Diagram" which returns a reference to the Diagram similarly to what "This VI" does (but not the top-level Block Diagram, the actual diagram in which the node resides i.e. Diagram within Event structures, While loops, Sequence structures etc.), I would have all I need.  I could then parse the rest in a sub-VI and return the required string without jumping through lots of loops to get there (or not, as I am currently experiencing).

10 Comments
Intaris
Proven Zealot

See HERE for another idea which could be solved by this.

 

Note, I now understand that going the "clone instance" route will probably never work, hence the idea to be able to pinpoint a static scripting location in code for passing as a parameter to a sub-VI. This essentially passes on the appropriate callsite information, or is close enough for me at least.

AristosQueue
Proven Zealot

Are you creating some sort of debug logger?

 

Can you give some details about why you're doing this? Scripting changes to the block diagram on a running VI is an unusual request. The only similar request I can recall is someone who wanted an on-diagram computation to be able to turn on or off a breakpoint on a specific wire (so the breakpoint would only hit if a condition was true), and the computation was more complex than what a custom probe could do (because the custom probe only pulls one value from the diagram).

 

 

Intaris
Proven Zealot

I don't want to do any changes to the code at all, I simply want to be able to retrieve information about code being executed (where, which time etc.).  I don't want to have to hard-code all the strings and stuff. Being able to tell a sub-VI where a specific reference point is and then go from there would allow me to modularise the code. It's more reflection than scripting but I use the tools available.

 

Specific example: I want to be able to easily add debug information for an event-driven architecture.  Instead of adding lots of statically linked strings et. al, I can simply let scripting methods query the status at run-time. I thought I could do this with a preallocated clone and then get the parent via Call chain, locate the sub-VI and match the clone instance.  Of course this matching of clone instances doesn't (and as I understood it, most likely never will) work.  Having a static placeholder for a scripting starting point (callsite-speficic) removes the need for this.

 

TL;DR

Yes I'm trying to make a debug logger

Intaris
Proven Zealot

I've kind of solved my problem in a different way.

 

I've written a Script to search for any event structures in a VI, and for each frame, see if there's a String Constant called "EventName" in there.  I then set the value of the string constant to the string visible in that frame of the Event structure (and make right-aligned and size to text - personal preference).

 

It's basically hard-coded Event names, but it works.  Given that sometimes LV messes up the order and assignment of the events anyway, it serves as a guide whenever I might need to manually re-assign all of my events.

AristosQueue
Proven Zealot

Intaris: Clearly that's a less-than-optimal solution, but I'm glad you found something that works. When you substituted the text, did you leave the original "EventName" text as a prefix so you can rebuild if you edit the events? Might be better to put "EventName" in the label of the constant instead of its value so that you can always do the rebuild without polluting your run-time strings.

Intaris
Proven Zealot

Yeah. When I say "String Constant called 'EventName' " I mean its Label.

AristosQueue
Proven Zealot

*nod* Glad it works; wish we had something better for you.

AristosQueue
Proven Zealot

Question: Would a "This Node Ref" be more useful than a "This Diagram Ref"? (A node that returns a reference to itself instead of a node that returns a reference to its owning diagram.) I'm thinking the node has a label that you could modify; the diagram does not, and you might have a need for multiple info points within the same diagram? Maybe? I'm just brainstorming here.

Intaris
Proven Zealot

Anything which gives a fixed statically-designed location which can be apssed as a parameter to a sub-VI would be just awesome.

 

I thought first about "This Node" but thought it might be weird syntax-wise, hence the suggestion for "This Diagram".  But essentially, it makes very little difference.  Once the anchor point is given, it's essentially the problem solved.

 

I mean, calling the "Owner" property on the item to get the owning diagram (unless it's in a cluster?) isn't exactly a huge amount of work is it?

 

I suppose "This node", without having inputs or other outputs is essentially the same thing as "This Diagram" but with a Label and a position.  Otherwise, there's no extra benefit from it, is there? Unless of course we can wire something up to its input (just as an anchor).

Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.

DNatt, NI