06-30-2015 12:17 PM
LV2013, Win7
I was trying to have a list of all the OPEN windows in my app (possibly 15+ windows, over 6 monitors).
So, I have each VI call a "Tracker" VI, with a VI REFNUM / NAME when it OPENS, and call it again with the same VI REFNUM when it CLOSES.
When the menu pops up, I can ask the tracker for a list of open ones and assemble the menu.
The menu will include, as the TAG, the VI refnum, so that when I choose one, I have the VI refnum and I can set the PANEL.IS FRONTMOST property to TRUE, and bring that window to the front.
Here is the code. Pretty simple, right?
It is INITed earlier to have empty arrays.
When the OPEN function is called, I look for the given RefNum in my list.
If it's not there, I add it. If it's already there, I ignore it (you can choose OPEN multiple times in my app).
Not shown is the CLOSE counterpart, where I search for the RefNum and delete it from the array.
There is a debugging line there, so we can see if it happens.
Well, it didn't work. My scheme consistently showed THREE windows open, instead of SEVEN I was expecting.
I added some debugging stuff and you can see the results below:
Note that the VI Refnum, EVEN THOUGH IT'S NUMERICALLY DIFFERENT from any in the array, is being registered as NOT DIFFERENT, in some cases.
It just so happens that those cases are reentrant clones - i.e. the "MiniChart" window is launched dynamically from an OPEN REFERENCE and CALL BY REFERENCE node.
So are the MegaMonitor windows - they are reentrant clones.
Still - the references are unique. So, how is it that the SEARCH ARRAY function is looking for the TYPE of VI being referenced, and registering FOUND if the type matches?
Blog for (mostly LabVIEW) programmers: Tips And Tricks
06-30-2015 12:24 PM
Sure enough, that's what's happening.
Since I have to convert the VI RefNum to a U32 and then a string anyway (to put into a Menu Tag), I can do the conversion earlier.
If I keep a list of U32s, and NOT a list of VI RefNums, then it works as I expect - all the refnums show up as new.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
06-30-2015 12:27 PM - edited 06-30-2015 12:31 PM
Obviously, it's not really comparing the RefNums, when doing the SEARCH ARRAY.
It's comparing some structure that they POINT TO.
For cloned VIs, that is a single structure and there's only one for however many clones you have.
I don't know WHY it would work that way, and I don't see a practical value to having it work that way, but there it is.
Thanks, folks!
Blog for (mostly LabVIEW) programmers: Tips And Tricks
06-30-2015 12:29 PM
There are certain objects in the VI server hierarchy where you can have multiple references pointing to the same object and the LV comparison functions know to do a deep comparison. I wouldn't have expected references of clone VIs to fall under that category, but your code seems to indicate that they do (I would guess bug rather than by design, but that's just a guess).
Anyway, you have a solution, so that's good.
06-30-2015 12:39 PM
Sure enough.
I used the EQUAL to compare each RefNum to the one before, and it tells me that these two RefNums are equal, when if you look at them as U32s, they are not.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
06-30-2015 01:46 PM
Here's an actual example (2011). Let's report it and see what NI says.
07-01-2015 04:31 AM
I also fell into this trap a while ago where I needed to see if a VI reference existed in a lookup table. I think I did something before where I look at the 'CloneName' property (which will error if the VI is not reentrant) and the equality of the VI references.
07-01-2015 11:14 AM
It used to be that comparing references just compared their numeric values. Starting aroung LV 7 or 8, that was changed so it's supposed to check whether the references refer to the same object (since that's what people would usually want to do when comparing references).
Attached is an alternate way to track open windows. It doesn't require you to put special code in each VI that might open it's FP.
07-01-2015 11:49 AM
It doesn't require you to put special code in each VI
Does it require LV 2014?
Like I said in the original, I'm in LV 2013.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
07-01-2015 12:03 PM
Never mind; I fired up a VM with LV2014 on it to look at your code.
Looks smart, using one VI to monitor activation events of another.
But it uses the VI NAME to distinguish them. Won't that fail if the VIs are clones? Don't the clones have the same VI NAME, or does that VI NAME get attached with a number?
In any case, I don't want the user to see those oddball numbers. He has to see "Unit 1", "Unit 2" or something.
I suppose I could use WINDOW TITLE instead...
Blog for (mostly LabVIEW) programmers: Tips And Tricks