Darren

Are you trying to close the VI interactively, or programmatically?

Scripting properties and methods are not supported in the run-time engine, so a built EXE does not have the ability to perform VI inspection.

Sure, here you go. Saved in LabVIEW 2012. OS Window and Native Window properties.vi

I have said almost those exact words on more than one occasion.

Open your main VI, press Ctrl-F, select "Objects", and specify a MathScript Node as the item to search for. Assuming your application doesn't call any dynamic VIs, and you have the "Search Scope" set to <All VIs in Application Instance>, this should find all the MathScript Nodes in your application.

My solution is to never, ever rename classes. I'm serious.

I just updated my OpenG libraries in LabVIEW 2013 and everything looks good. For posterity, the new palette object names I observed were: OpenG Array Palette Empty Array? (OpenG) OpenG File Palette Build Path (OpenG) Strip Path (OpenG) OpenG Time Palette Tick Count (ms) (OpenG) Wait (ms) (OpenG) Wait Until Next ms Multiple (OpenG) With Jim's changes, all 6 of these OpenG VIs are now droppable with Quick Drop, and they display the proper owning palette when you right-click them. Thanks for implementing the fix, Jim!

I have added a link to this post to the CAR, and indicated that we should prioritize this over some of the other CARs I've filed about moving private stuff to public/scripting.

I discovered another reason, independent of Quick Drop, that these duplicate palette name issues should be fixed. When you right-click on a subVI, you don't get taken to the correct owning palette for identically named items. Right-clicking on an OpenG File VI should show the OpenG File palette, like this: When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:

I suppose you could consider it a "bug", although this is the first time in Quick Drop's six-year history that I've heard of somebody wanting to include a bracketed suffix in a palette object name and have it *not* refer to the owning library. Speaking of libraries, I just confirmed with Stephen that, if you namespace an existing VI with a library, but leave the VI's location and name on disk unchanged, then existing code that links to that VI should automatically relink to the newly-namespaced VI without issue. We've used this trick at NI on several occasions when adding library namespacing to existing APIs...I see no reason why it wouldn't work for the OpenG libraries as well. So again, the very low-budget solution to this issue would be to figure out the OpenG palette objects that share names with core LabVIEW functions (it looks like there are about 6 of them from the discussion above) and add an "(OpenG)" suffix to their window titles. The more elegant solution would probably be to add libraries to namespace the OpenG VIs. And looking forward, I've never particularly liked palette VIs that have different palette names than their VI filenames (the exception being Merge VIs). Hindsight is 20/20, but I probably would have just named these VIs something like "Build Path (OpenG).vi", with no custom window title/palette object name, from the start.

Unfortunately, brackets in palette object names are treated special by Quick Drop, so suffixing with "[OpenG]" would not work. Any other delimeters (parentheses, braces, etc.) should work fine, though. I think I'd prefer if we kept brackets as a library name designation, so if you did suffix the OpenG object names, I'd prefer it be with parentheses.

Palette VIs that are namespaced with libraries (or classes) appear with the library name in brackets, like so:

Quick Drop will list multiple identically-named objects if they are namespaced differently. So one possible solution would be for OpenG to include all of their palette VIs in a library...this would cause both "Build Path" and "OpenG.lvlib:Build Path" to appear in Quick Drop as separate objects. Assuming OpenG does not want to start including palette objects in libraries, I thought the renaming option was a simpler and more viable solution.

I've been making a pass through all the LabVIEW palette content on my system, looking for duplicate names between palette objects. Since Quick Drop will only list a single object of a given name, I think it makes sense that all unique palette objects should have unique names. I have come across three OpenG VIs that have identical names to built-in LabVIEW functions (and thus, cannot currently be dropped with Quick Drop): Empty Array? - user.lib_OpenG.libarrayarray.llbEmpty Array__ogtk.vi Build Path - user.lib_OpenG.libfilefile.llbBuild Path__ogtk.vi Strip Path - user.lib_OpenG.libfilefile.llbStrip Path__ogtk.vi Currently, these VIs use window titles to define their palette entry names. Would it be possible to update the window titles of these VIs to have different names than the core LabVIEW functions, thereby allowing these three OpenG items to be droppable from Quick Drop?

High Resolution Relative Seconds.vi works on all desktop platforms, and it also works in RT.

Here are this year's BBQ limericks. If you find that your woman is yearning, for a good dose of sweet LabVIEW learning. Show her 2013, where the examples are clean, and no longer cause stomach churning. A weirdo who loved C++ Met JeffK while riding the bus. A discussion transpired, His brain got rewired, Now the weirdo loves LabVIEW like us! You’ve heard of this framework called Actor, Well it’s great for your LabVIEW geek factor! When a girl sees your app, It won't look like crap, And you can use that to somehow attract her. You might wonder how I got so skilled, At getting lim'rick orders fulfilled. I have plenty of time To work out the rhymes, ‘Cuz my app takes 4 hours to build.

Argh, you're right. When I checked this morning I was awash in several open LabVIEWs and checked the wrong one. The "Focus Item" property of the TreeControl class is only available in LabVIEW 2013 and later. I have updated my post above to reflect this. Sorry about that.

The FocusRow and FocusItem properties are still private in LabVIEW 2013. I will add them to our internal list of properties to consider moving to public/scripting in LabVIEW 2014.

From what I could tell, we were *supposed* to see the focus row be correctly set while editing in 2013, but from my preliminary tests, it appears to still be a problem in 2013, and will thus still require the programmatic workaround.

I didn't think they did, but I was pleasantly surprised when I looked this morning. Here is the same property for the Tree (saved in 2012), also only available in 2012 SP1 and later. tree_FocusItem.vi Edit: Turns out the "Focus Item" property of the TreeControl class is only available in LabVIEW 2013 and later. My previous statement that it was available in 2012 SP1 is incorrect.

There are some private properties you can use in LabVIEW 2012 SP1 and later that allow you to set the focus row of a Listbox or Multicolumn Listbox programmatically. Whenever you programmatically change the value, if you also programmatically change the focus row, it should behave in the manner you're looking for. I had heard the behavior was fixed natively to the controls in LabVIEW 2013, but it appears to still be an issue that we have to workaround programmatically. This VI (saved in LabVIEW 2012) contains the private properties you would need. Again, these properties were added in 2012 SP1, so they're not available in an earlier version. Oh, and it was a top woman, not a top man, who added these private properties for us. Focus Row Properties.vi

In my case, the password they sent me had a lowercase "L" that looked like an uppercase "I". Once I figured that out, it worked for me.

Yes, Jack asked me to do some again. I promise I won't forget the lines to any this year.

I did get a chance to fix this issue for Quick Drop Ctrl-I in LabVIEW 2013. The issue has not yet been addressed for Ctrl-Shift-I.

Here's a VI that shows how to do the same thing, but with public properties/methods. Saved in LabVIEW 2012. Get Owning Project Name.vi