Darren

Also check out this VI.

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

Traverse for GObjects.vi is available in Quick Drop/the palettes, so it's documented. It helps you find all the objects of a particular class within an arbitrarily nested panel, diagram, or object. As for finding a specific object with a specific label, there's a VI for that too, although it's not documented...check out <LabVIEW Dir>\vi.lib\Utility\traverseref.llb\TRef Find Object By Label.vi. This VI wraps Traverse for GObjects.vi with extra code to do the label matching. Let me know if y'all have any questions about either of these VIs (or any of the other goodies in traverseref.llb, for that matter).

The only way I was able to get the "strict" control references was to create a control reference control, right-click it and choose "Include Data Type", then create a constant from that strictly-typed control. In general, I only use "include data type" when I'm dealing with a control that can have different data types (like a listbox, which can be a scalar or an array), and I want to make sure that the VIs I have that may operate on the value of that control will only accept a strictly-typed reference.

I should also point out that the easiest way to get a control reference control of the correct type is to drop a Control Reference from Quick Drop/the palettes, then drag a control into the control reference to define its type. I'm pretty sure that's how I created the control references for the QMH template.

The risk with a system like this is that it is very easy to end up with the queue communications embedded within your code modules. This can reduce the reusability and scalability of your application so I prefer wiring the reference, especially as 3 of your functions just wrap queue primitives anyway.

Yeah, what he said.

It seems like none of your RSS feeds are compatible with this forum import tool.

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.

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