brian175

I've looked around a bit, but I haven't seen any examples of someone using scripting to add an existing subVI and connect the terminals. If I wire a subVI path to the "New VI Object" primative, I can add a subVI to a diagram. But I can not get a reference to the terminals to wire it. Can anyone help? Thanks, Brian

Here's another approach, but it will not work on VIs inside of llbs. I have only done some very limited testing but it appears to work on LV 6.0 and above. I don't have a 5.1 file but 5.0 files have a different offset. Download File:post-987-1123081710.vi

Oops, I guess that I should have read the entire thread!! Sorry Jim, I should have known better.

LAVA has to fix the RSS feeds! Sorry I didn't answer sooner but I never saw the post. Jim your solution seems a bit extreme, why not just use the application method "Get VI Version" thats what I use in LVC.

I do not know of a way to add a version number so it can be read by the GetFileVersionInfo function, but I do have a way to store version information in any VI including those without a diagram and/or front panel. There are a set of VI properties exposed for scripting that allow reading and writing tag information to any LabVIEW file. I have found this so useful that I have created a toolkit called VI_Tag Toolkit. There is a beta release available on my website. I use VI tagging to add version information to all of my applications and toolkits. I recommend creating a string tag with the following naming structure "company.product.version" for version information. For example the dqGOOP Toolkit has the string tag "DA.dqGOOP.Version" which can be read to get the version. Here are the links: VI_Tag Information Download link Brian

It depends on whether you are using the tree control to store the data or display it. For example the tree example that ships with LabVIEW takes directory and first reads every file and sub directory and then adds to a tree. Here they are storing the entire directory structure in a tree (which takes a very long time). I wrote a tree control utility that only fetches the items as they are needed. So in my tree I only get the files and directories of the top level directory and when the user expands on a directory, then I get its contents and add to the tree. So in this case I can browse C:\ which has well over 1933 items but the tree control only contains the items that are being viewed. The tree never contains all the data, just what needs to be displayed. I don't have time right now, but hopefully I can post an example if it would help.

Don't hold your breath, I reported this same bug in LV 7.0 back in Feb 2004

Jim describes the OpenG resource "Rename Folder of VIs..." as a workhorse and it is true, I use it all the time. However, I typically use it to use an existing GOOP class or project as a template for another. As a result, I always have to first copy the source in Explorer and then rename. I modified the original routine to incorporate this step. Just drop the library in the ../LabVIEW 7.0/wizard directory and restart LabVIEW. (I can save down to LV 6.1 if needed, but not lower since I switched to an event structure to handle the UI. Brian Download File:post-987-1117024952.llb

Yes dqGOOP uses the type cast, but LabVIEW doesn't allow a (reentrant?) VI refnum to be the input type to the type cast function. I remember reading that the flatten => unflatten was the "trick" needed to enable converting the Object refnun to the VI data store refnum.

Converting to 6.1 will not be a problem, but performance is worse. dqGOOP takes advantage of internal optimizations that NI made to the queue in LV 7.0 and later. Converting to 6.02 will cause some broken arrows since the structure of the queue changed from LV 6.0 to LV 6.1. For one, there isn't a "preview" function in the 6.02 queue which is used by the getData function. You could possibly work around by using status or just dequeue and enqueue in the getData function. I need to rerun my 6.1 performance test, but I think that niGOOP was the overall winner, but OpenGOOP was faster for set and get operations.

This time I'll try a zip file Download File:post-987-1116208154.zip

The attached spread sheet has some performance data on OpenGOOP, niGOOP (GOOP) and dqGOOP. I created dqGOOP for performance, but unfortunately it requires LabVIEW 7.0 or later (it sounds like you're using 6...). Mark Balla started a discussion on dqGOOP here: http://forums.lavausergroup.org/index.php?...=1392#entry4739 The first post has a zip file GOOPTest.zip that has three test classes (LV 7.0) and a performance test VI for each (in the Testing folder). [Two weeks of discussion on dqGOOP was recently lost due to an attack on the LAVA discussion forums] OpenGOOP doesn't support named objects, but since it is open you could add that functionality. dqGOOP uses LabVIEW native queues so it supports named objects, with the added advantage that unique references are created when you obtain a reference by name. I have not been able to test GOOP 2.0 performance or the new GOOP developer posted by Kurt Friday at: http://forums.lavausergroup.org/index.php?...=1355#entry4509 Brian

NI support has a download for the same "Show Buffers" utility that is available in LV 7.1 for LV 7.0 :thumbup: Here is the link http://digital.ni.com/public.nsf/3efedde43...4a?OpenDocument This is an excellent tool if you are trying to optimize your code. The attached images show how something as simple as wiring the error cluster to a case input and reusing the same wire of the case input can cause a new buffer to be created.

Here's a modified version of Michael's VI that doesn't have a "huge" performance hit. The trick is to minimize the number of times that the VI calls itself (due to the Open VI reference call). On my computer the listing of the LabVIEW directory took the following times: Michael"s VI 2399 (ms) Rolf K's VI 478 (ms) Michael's VI modified 552 (ms) OpenG 6717 (ms) The test VI as well as Michael's and Rolf's original VIs are included. Brian Download File:post-987-1100028178.zip