Is there a way to programmatically remove VIs from memory?

[mikeporter]

Uh yup, you're right everything was getting written--except the data. Oh well... It was getting late last night.

In any case, I have played a bit more and attached is a version of the VI that does save the data and cleans some other stuff up as well. For example, note how I write the data to the subvis. Although I have heard that this method is not quite as efficient as using indexed control references, I prefer it because it is more robust in that it isn't dependent upon a hidden parameter (tab order) to stay connected to the right controls.

Note also the data passing. To maintain the polymorphism of your interceeding code layers, I converted the application-specific data types to a variant data type. In this way Remember Values and Make Current Default can handle the data without worrying about what the real data type is. (Actually something you might want to consider is whether the you still need both of these VIs...) The only other impact to passing variants is that the template VI has to make the conversion back to a LV datatype so I had to add a Run VI before saving the new defaults. Reading the data shouldn't change because the "Read" case bypasses all the code so all you'll see is the output's default value.

Using variants as a polymorphic data type is a very helpful technique, take some time to be sure you understand it. You will want to use it again sometime...

I have also cleaned up the error passing so all errors will eventually find their way back up to the top level VI and be reported. In addition, I added a case structure to prevent the creation of an extra spurious data VI. The problem is that the database assess node doesn't assert EOF until you have read past the end of file. You might want to look up how to access the log files using the standard file IO VIs. That approach might be more flexible is you have several log files of each type to convert.

If you have any other questons on what I have done just ask...

Mike...

[Brock Greman]

I'm going to have to spend a bit of time familiarizing myself with the new system.  One of the advantages to the system I had used before was that it was easy for a user to create a new template and writer for his own data type, which could be readily incorporated into the polymorphic VI.  This is of importance because my position in this lab isn't permanent, so I won't always be there to guide them through updating the software.

If my understanding is correct, the new version of make_current_default now requires that certain controls on the template VIs have very specific names.  The software itself does work like a charm, although I believe the 'read' and 'write' cases in the template VIs may need a bit of altering to make them make more sense.  Basically, the user should be able to drop a data VI into another block diagram and access the data from an output terminal.  I'm also going to eventually write a data browser which will be able to accommodate all the data types.

This is not to underscore the extreme help you've been to me.  The software has become so much more sophisticated thanks to your assistance.  If you send an e-mail to me a bgreman[at]gmail.com with your name and institution, I'll make sure to credit you as a source and collaborator on the software package.

Thanks again,

Brock

[mikeporter]

Brock;

I am sending this same information in a private email, but am repeating it for the sake of anyone else who might be following this thread...

I hear you in terms of ease for your users to create their own templates. However, with a couple minor modifications to the code, it still shouldn't be too hard to describe what they need to do. Starting with the data template. On the diagram there is a hidden control of the proper data type connected to the top terminal of the function for converting the varient back into "their" data type. Replace this with a local variable created off the output indicator. This way when a user is wanting to create a new version, they just have one indicator to change to create a new template type and then save the VI with a new name (with a *.vit extension!).

In terms of the polymorphic VI add-ins, modify the code I sent you last to move the name of the template to be opened into a front panel control that has the proper name stored as the default. All your users would then have to do to create their own version of the polymorphic VI is to change the name in the control to match the name of the template VI they already created, save new front panel defaults and replace the input data control with "their" data type. Everything else should just work... (Oh yes, they'll of course need to add their new write VI to the polymorphic VI.)

Mike...

[Ben]

Nice work Mike!

I assume you wrote "Error Fork Stacker.vi". Do I have your permision to re-use that VI in the VI's I develop for my customers? It is a nice approach to multiple error threads.

Ben

[mikeporter]

Go for it Ben.

Mike...

[mikeporter]

Brock;

One more thing. I was thinking about your comments last night and it occurred to me that you could actually write a small utility program that would create your users' VIs for them--and it wouldn't be horribly hard. What do you think?

Mike...

[Brock Greman]

This had been my goal from the start, but I eventually abandoned it when I determined that, as far as I know, you can't dynamically add or remove cluster elements and maintain their naming properties.  Since being able to access the cluster elements by name is of paramount importance, I decided that teaching the others to build their own templates was an acceptable solution.

[mikeporter]

Brock;

You're right, you can't progamatically edit clusters. However, if you play your cards right you don't have to. All you have to do is take advantage of a feature in LV that many people think is a bug. Consider for a moment that you have a VI (named template.vit) that uses a typedef control named (for the sake of argument) template.ctl. If you have any control open in LV with that same name when you open the VI template it will link to the one you have loaded into memory--not the "correct" one from the disk. Essentaily you will have replaced one control with another one. Once the new link is established in memory, save the control and VI with a different names (in that order) and badda-boom badda-bing you have a new VI that is linked to a different control than you originally created it with.

See where I'm going with this?

To prove it to your self that this works, you can do it manually. Then all you have to do is write a small program to use VI server calls to do the same thing...

Mike...

[Brock Greman]

Hmm.  I'll certainly look into it.  I've got a bit of work ahead of me to wrap my brain around everything you've done.  Again, a million thanks for all the help.

[Brock Greman]

Hi again, Mike-

My employer was thrilled with the new implementation, and it's beginning to be adopted by my colleagues.  However, I have a slight concern.  Each written data file is twice as large as original data it contains.  I know why this is, actually.  The variant type data in control on each data VI's front panel is also having ITS contents saved as default values.  I'm wondering if there's any way around this...