How to find icon position of currently executed VI on caller's block diagram

[Hooovahh]

I was actually refering to the snippet in message 5.  It isn't complete, but the idea is that you could call this VI as a subVI at the start of each step.  It could then get the location on the block diagram that it is running from, and send that to the main UI somehow, maybe user event or queue, or even polling a global might not be a bad idea since VIs could complete quickly.

Also this is only going to work from source.  As a built EXE there is no block diagram, and many scripting functions just don't work.  Not sure what your requirements are but it could still be do-able with extra work, like including block diagrams in EXEs, or build some of the resources needed before the EXE and include them, like static images of the block diagrams.

[cpschnuffel]

Hi Hooovah,

I was the author of this snippet 😉 I absolutely agree with you that this snippet only works in LabVIEW IDE (because of LabVIEW scripting functionalities), but this is how it will be used.

But the main problem of this snippet is that it collects ALL icon positions and bounds of the specified VI, not only of the running one. Example: You have a main program like this:

This calls the same VI three times. <Untitled 1.vi> contains the code snippet above and always returns all three positions/bounds:

But which is the running one? That's the great question I try to find out...

Regards,

Carsten

[Hooovahh]

If the sequences are as simple as the user originally posted, then we should assume that the first time it is called it will be the left most copy, the second time it will be the second from the left.  This of course is only true if data flow is always from left to right, and is sequential, and it looks like sequences are meant to be this type of VI.

[tst]

I haven't read the thread too closely, but might I suggest you get your client to read this - http://en.wikipedia.org/wiki/Inner-platform_effect

After they're done being insulted, and if they're not convinced, I would suggest that you add a simple reporting VI which is called after each subVI. If the user is smart enough to write LV code, they should be smart enough to drop those.

Another option is to look at the DETT, but I haven't looked closely enough at its capabilities and I would expect that abusing it for this would probably not end well.

Overall, I would suggest that an alternative display for the progress would be better. If they really want to write VIs and have at least some of this automated, this could probably be done by using static VI refs and call by refs instead of a standard VI call. That way you can at least plug the reference into a logging VI which will get its name.

[cpschnuffel]

@ Hooovahh:

Of course it is only a simple example I gave you. You cannot assume that the VIs are always ordered like in the example. I'm still evaluating your discussion links from message 9, which are very interesting.

@ tst:

I will have a deeper look at DETT and give a feedback if it is suitable. Of course there are many other reporting capabilities I also regularly use in my LabVIEW projects (log files, status bars etc.), but IMHO it is very exciting to evaluate THIS way...

Regards,

Carsten

[cpschnuffel]

@Hooovahh:

There are some useful hints within your linked content, one also refers to DETT...

@ tst:

DETT looks VERY promising!! Stay tuned!

Regards,

cpschnuffel

[cpschnuffel · Accepted solution]

I think I got it:

<Untitled 1.vi> contains the following snippet:

Having a look at the content of the <events> indicator, you will find the <VI Call> and <VI Return> events with the corresponding subVI UID (!!!), and with this UID you are able to get position and bounds of the corresponding VI icon (perhaps it makes sense to run the Desktop Execution Trace Toolkit to compare its results with the contents of <events>).

To get the invoke nodes "App:Desktop Tracing:Setup" and "App:Desktop Tracing:Get Trace Data" you have to add "SuperSecretPrivateSpecialStuff=True" to your <LabVIEW.ini> ;-).

I know that this is not the final solution, but I think the rest is a peace of cake...

Regards,

cpschnuffel