Flagging controls for future actions

[kc64]

I have a front panel that contains two classes of controls:  those that are user interface-related and those that are programming related.  The status of the UI-related controls is to be logged into a database when I click the Update button.  On the other hand, I really don't want to log the status of the Update button or the error cluster, for example.  Is there a method of marking or flagging controls into classes or groups so that an iteration over all controls can take action if the control is flagged?  Is there some other way to do this other than enforcing some label/caption naming scheme that has a marker as a flag?

[Ben]

Not usre if I follow all but I talk about what your posts made me think I read.

I have an old "Save All Controls" that runs through all of the controls on a FP and saves/restores same. Supported by that code is an "Exception list" that list all of the controls that I do not want to save/restore.

About the only least offensive emthods of flagging objects could make use of the description of each object such that if it contains the phrase "back-uped by..." then ...

That would at least add some documentaion value as well as getting the switch you are after.

Note: I don't think will work if you ever plan to deploy to RT target that can't use property nodes.

Ben

[JÞB]

In adding to What Ben suggested.  You will need to use some VI property to distinguish between yor "classes" of controls.  instead if using the caption you COULD flash the controlls you don't want to save invisable and switch on that property.  I'm guessing the "don't want to saves" are pretty constant.  Or use "is Dype def." Or use a decoration around the UI objects get its bounds and compare to the bounds of each control.

[kc64]

Thanks, guys.

I've decided to use the Caption as the flag.

[kc64]

Or not.  Caption causes errors.  Switched to Description.

[tst]

I would suggest neither the caption nor the description. They each have their own purpose and overloading them is not necessary.

Personally, I prefer explicitly building the references of the controls I want into an array and passing that array to a subVI. See here for a simple example:

That example uses the OpenG VI internally, but you can easily replace it with the NI VI if you flatten the variant to a string. The same concept can apply to saving to a DB. This RCF plugin allows quickly building an array of references for selected controls.

Another option which is more elegant than using the description is assigning a tag to each control you want to edit. This is more elegant, but requires building an edit time tool which will allow you to edit tags on controls, since the only way of accessing them today is through a reference to the object which has the tag. You can build such a tool, but it requires a bit of know-how. This VI (basically a floating tool which allows you to manipulate selection on the VI you're currently editing) will get you some of the way there and also show you where the tag VIs are.

[kc64]

Thank you for your post, tst.  The problem with the approach of tagging the controls that you wish to log is that the code that does that will have to be modified any time a control is added.  By flagging those that are not to be included, additional controls can be added without changing the code that logs those values to the database.  This may be a minor thing for a LV guru but for those who follow you in the design cycle, it may not be so obvious.

[tst]

I think you may have misunderstood me. There are two completely separate methods in my post -

1. Explicitly creating a reference to each control, as shown in the image. It does requires adding code if you want more controls, but you would also need to do work if you "flag" the control, so I don't think you should consider that a problem.
   Also, being explicit has the advantages of the info not getting lost and not being hidden. I personally prefer this for something like this, although every rule has exceptions.
2. Using a tag for the flag instead of the caption. The tools needed to do that are shown in the VI attached to the previous post. I prefer this to the caption or description because that's exactly the sort of thing it's designed for (attaching custom data to an object), but I don't like it because there's no existing interface for it and because it's hidden. Both things which can't be solved, but which I would only wish to do under particular circumstances.

[kc64]

tst--

I see more clearly now.  I've been searching all over for UserTags.lvlib to no avail.  There is no help on the VI either.  Searches on the NI site yielded no hits.  Any pointers?

[tst · Accepted solution]

The VIs exist on your system. They've been in vi.lib\UserTags since LV 8.6 and you can easily see that by opening one of them and doing a save as or opening its VI properties dialog.

Here's one of Darren's nuggets about this.