Darren

To my knowledge, there is no way to call the functionality in the Find Dialog in a VI.

Remove Frame is a method of the MultiFrameStructure class. Since there's currently no mechanism in VI Server to hide parent methods in child classes that don't implement them, we see it in the list, but get an error that it doesn't work.

I've complained about the lack of scripting support for the Event Structure for years. Everybody reading this thread really needs to go kudo this idea.

I don't think so. If something else is keeping that VI in memory (in this case, it would be the fact that it's owned by a class), then I'm pretty sure that setting isn't doing anything....well, assuming your class is in memory the whole time.

Oh man, that was funny. And oh so true.

I didn't realize you were the one who added that VI, Rob. I've recommended it in multple performance presentations over the past couple of years, and your comments here and on the ni.com thread give me some extra details to include the next time I discuss it. Thanks!

I never noticed the Defer Drawing before, but I have an educated guess as to its purpose - the FP has a defer updates property which is useful when you want to make a lot of updates in sequence, but have them appear as a single update, either for speed or for elegance. I'm assuming this is a parallel property which was designed for scripting - if you want to make a lot of scripting operations, you don't want to waste time on drawing all the intermediate steps.

I'm not sure why this is in the Application class and not in the Top Level Diagram class, but that's possibly because it's expected you would edit more than one VI or because of implementation details or because it's for something else entirely.

There's already a private 'Defer Diagram Updates' property on the TopLevelDiagram class. I have no idea what the App.Defer Drawing property is used for.

Does Active in this context to the VI with FP focus? If there's any context help for that I don't have the ability to reference it right now.

It's the VI whose front panel or block diagram window currently has focus.

App.Get Active VI Ref? That one could be useful, Darren.

Definitely useful, as it was added for one of my features back in LabVIEW 8.6. I've added it to my list.

Could you post a screenshot of the menu or whatever else it is you use to customize that? It's not like it would give us access to any features NI doesn't want us to have, just satisfy my curiosity about that kind of thing.

No, I can't post a screenshot. Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

As a general rule, if it's an App method that takes a VI Path as an input, it's giving you VI information without loading the VI into memory. If it's a property of the VI class, then it requires the VI to be in memory.

Not a special compiled version, just a certain way we can configure the UI to make controls generic.

The "wider LabVIEW audience" doesn't include all the l33t h4xx0rz talk on this thread, so don't expect any of the DFIR compilation or Licensing stuff to ever become public. Keep in mind we need to run any public/scripting VI Server stuff through rigorous documentation and testing before releasing it to a wider audience. As has been mentioned multiple times by myself and AQ in the past, something is private usually because it's been designed and used for one specific use case, with no other cases really documented or tested.

Now, Get Shell Icon of File, on the other hand, I could see being useful to the general public. I'll put that on my list to advocate for LabVIEW 2013.

You can right-click on the top-level project item and choose "Find Items with No Callers". This should generally do what you want, with a couple of caveats:

1. Your top-level application VI(s) will be listed, so ignore those.

2. Items in Dependencies will be listed. "How is something with no callers in my Dependencies list?", you may ask. Well, unfortunately, if there is a library in your Dependencies, then any VI in that library that you don't call in your code will be listed in the "Find Items with No Callers" results. I've been meaning to add an option to that dialog to ignore Dependencies for years, but I haven't gotten around to it.

"Top 10 letters Darren is least likely to ever have to write"

Damnit, Stephen, stop showing me expensive things that I want. Thankfully, Cubelets are so over-the-top expensive that the practicality of putting food on the table immediately overrides my normal impulse of reaching for the credit card. Now, if they were about half that price, I don't know if I could control myself...

I've only ever used Class Operator in conjunction with the Traverse method. You set an operator VI that runs whenever the Traverse method finds an object matching the class name you specify. For my Traverse VIs, the operator VI is very simple...it just adds the found object's reference to an array. I know other people have written their own traversal algorithms that have the operator VI do a lot more stuff when it finds the object.

The following VI is available in LabVIEW 2010 and later...you should be able to dig through it to find out everything I know about the Class Operator and Traverse methods:

<LabVIEW>\vi.lib\Utility\traverseref.llb\Traverse for GObjects.vi

Can't wait to hear more of Poet Laureate Nattinger's limericks...

Oh man, my creative juices are spent after writing (and memorizing) those limericks last year.

Please...don't make me do it again! (insert preemptive TWSS here)

I currently have 3 monitors (two up top, one in the center below). Hope to get a 4th soon.

I haven't seen this in 2011. But in the past, I have seen major bog-downs in text search for projects containing lots of picture control stuff, since (I think) the string search actually parses picture data as string data. Do the VIs in memory that you're searching have a lot of picture control stuff going on?

I had this issue in the Quick Drop window. And for reasons I can't remember now, I wasn't able to use a system combo box. So my solution was to have a frame decoration, with the same color as the panel, that I position exactly where that ugly black box would be. And the decoration is higher up in the panel order than the combo box. So when I assign key focus to the combo box, you don't see the ugly black border because the panel-colored decoration is above it. I also have to resize this decoration on a panel size, to ensure it's always surrounding the combo box at exactly the right size.

Programming UIs in LabVIEW is fun!

That onesie rules!