Jim Kring

Use an array of Clusters. One element of the Cluster should be an integer numeric, which is the link to the next element in the list. -Jim

Ya but if the subpanel is closed already, it generates an error. I guess i should turn off that pesky internal autoerror dialog... Automatic error handling isn't for "application programming", it is for "express node configuring". Now turn it off, already, before people start making fun at you

Here is a revised example that closes VI FP Prior to subpanelling the plugins. If you want to re-open them afterwards, you could do that, too. Too bad you can't check if the diagram is open and reopen it after subpanelling. I'd love that VI Server feature :wink: -Jim Download File:post-15-1073110109.zip

I think that your assumption is wrong. The Remove VI method's documentation states: If you have an open reference to the VI it should keep running. It may be aborting because LabVIEW is unloading due to the fact that you don't have an open reference to the VI. Use a "Message Queue" which allows you to use "Response Notifiers" (visit the OpenG.org site to take a look at this project) Take a look at the other thread that I started here. There are lots of different ways to use subpanels and most will require some wrappers that implement the desired functionality. The wrappers have access to the VI reference so they can look at the VIs state, set/get control values of the VI, etc.

Actually this idea should be extended further to allow probing any terminal that is a data source. Your example provides a perfect use case.

That's interesting, it's not in my full version... Anyone else to confirm this? It's not is my Professional version either :wink: Too bad that you can't get a block diagram reference and unhide your objects like you did for hidden SubPanels :roll: There I go again with the crazy talk!

Yes, this seems to be the only control that doesn't have a terminal on the block diagram. I can't understand why they didn't just do what they did for ActiveX Controls -- have the value of the subpanel be the Reference of the contained object, in this case the VI reference that is subpanelled. (of course you wouldn't be allowed to write the value, only read it, because the subpanelled VI is set with the "Subpanel VI" method). Now that I think of it, I don't think there is a way to find out the reference of the VI that is being subpanelled.More food for thought: Decorations can't have explicit references, or property/invoke nodes on the diagram. Decorations can also be hidden on the front panel, travelling around in VIs undetected. What we need is an UI that gives an inventory of the object on the front panel of a VI. You can use VI server to do this. Just get a reference to the VI and then get its 'Panel::All Objects" property. Take a look at the Copy-Paste Boolean Attributes project at OpenG.org. It uses this technique to operate on FP controls. http://www.openg.org/projects/project.cgi?ID=7 -Jim

What ever happened to http://digital.ni.com/lvwish.nsf/lv+wish ? It is now redirected to an "Email NI" submission form. Here's NI's new way of getting user input on the direction of LabVIEW: LabVIEW poll "Features you would like to see in LabVIEW!" They're sure setting themselves up for success :roll:

I noticed that NI updated App Note 154 to now include Variant, Refnum, and Waveform Data Type (WDT). This is great! They even describe the new subtypes of the WDT like timestamp, dynamic data, and the various waveform types. Way to go NI! Download File:post-15-1073109843.pdf

I am interested to see how people are using the new Tree Control. Are you going to use them in conjunction with an event structure? For example there are some pretty cool tree structure events: Tree Events (unique to Tree Control) * Double-Click * Drag * Drop * Item Open * Item Close As I see things, a Tree Control is a tool for visualizing some data structure (as opposed to a control that actually stores your data). When the user changes the tree control, by dragging and dropping items, one then has to capture information about the changes and then implement changes to the data structure that the tree represents. The Tree Control's events seem critical in this process. More power is given to also Filter events. For example, if the user does some Illegal action, the event can optionally be discarded. Have you learned any insights that might be helpful to others? One thing that I discovered is that in order to clear the entire contents of the Tree Control you have to call the "Edit Tree Items:Delete" method and pass an empty string to the "tag" input (shown in the image below). This was very non-intuitive, to me. I don't like functionality hidden inside of other functions -- I would prefer to have another method called "Delete All".

There are a couple uses that I can think of off-hand: Synchronously + Call-By-Reference This would be just like how you would call a subVI, except that you want its UI to be sub-paneled. In this instance we would (1) sub-panel the VI, (2) Call the VI by reference, and then (3) un sub-panel the VI. You can even make the plug-ins flexible by using variant data in and variant data out. Asynchronous + Data Messaging This would be more like how you would interact with an ActiveX control. You would sub-panel the VI, which is executing asynchronously. It has its own process (while loop) and it executes continuously until it receives a "shut-down" message. You would message data into it and out of it using queues, notifiers, or some other means. This allows you to effectively create controls with code behind them. :arrow: I have attached an example of the 1st use case (Synchronously + Call-By-Reference). Any other ideas? Download File:post-15-1073110083.zip

LabVIEW 7's app builder has added a VI for programatically building apps. I have created this command line tool. However, it requires that LabVIEW development environment is running :cry: Usage: build.exe -- RelOrAbsPathToScript -Jim Download File:post-15-1073109764.zip

Yes, NI knows a way :wink: Sounds like a good one for the wish-wiki. Cheers, -Jim

Hello LAVA folks, I wanted to invite anyone who is interested, to take a look at a new tool that I created. I call it a "Message Queue". The nice thing about this queue, is that when a message is enqueued a response notifier may be obtained. Then, when the message is dequeued by the message handler, the same notifier is returned. Finally, when the message handler is finished processing the message, notification can then be sent back to the message generator. You can download the tool at: http://osdn.dl.sourceforge.net/sourceforge...eue-6.0.1.0.zip The download includes a simple calculator example and installation instructions. It is packaged so that you can just drop the tool into your user.lib folder and a pretty palette will appear. Let me know what you think. Obviously this doesn't solve all messaging problems, but it does address simple message and response needs. I am interested in your feedback and seeing any interesting examples and use cases that you come up with. -Jim Kring