Darren

Weird. Here are all the RSS feed URLs I could find: http://labviewartisan.blogspot.com/feeds/posts/default http://labviewartisan.blogspot.com/feeds/posts/default?alt=rss http://feeds2.feedburner.com/labviewartisan I recall sending you the first two to try, but not the third. Is it broken as well?

What can I do to get my blog to show up in the Blogs forum? I think the stuff I post is pretty complimentary to Christina's and Michael's blogs, which currently show up there.

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

Here are this year's limericks...including the one I forgot the words to while I was on stage! A Quick Drop programmer named Nate Devised a plugin so great! But when he pressed Ctrl-Space He soon got a long face When it said, "Populating List...Please Wait." My UIs you all will extol, 'Cause I only use Silver Controls. My only real problem Is that when I drop them They eat up space like a black hole. For ten years we've had egg on our face. Event Structures were missing in Base! But now they are there Which lets us declare That all polling loops are a disgrace! A Tools Network partner named Klaus Was an expert with Quick Drop and mouse. The add-on he sold Was certified gold And its revenues paid for his house. There once was a coder named Norm Who used LV Speak during a storm. Not wanting to go out He let out a shout-- "Get Pizza!"...and food arrived warm. My VIs were password-protected. So why am I now so dejected? Some noobs made some toys Which sadly destroyed The edifice NI erected. Thanks again to Justin for writing some of these...his are the good ones.

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!

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.

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

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

Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

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.

Over the past few years, I have advocated that several private properties/methods that could be useful to the wider LabVIEW audience be made public/scripting. I have been largely successful. Please let me know (on this thread, or with PMs, or whatever) if y'all come across private entries that you think would be useful, and I'll see what I can do to make them official in a future LabVIEW version.

Last year I had a product mostly ready to go that made heavy use of this functionality, but I had to rip it out fairly late in the process because of some fundamental flaws (mainly #1 in asbo's list, but also some other issues). Please don't rely on this functionality in any app that you're not planning to throw away.

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

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?