From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Well, I did a search prior to post this and I read Paul suggestion. As far as I can see this is not quite the same. I don't really think that we need for the decorations to have labels. What we need is the capability to create explicit decoration references.
Pauls post says "optional labels so that they can be addressed programmatically", and addressed programmatically pretty much means reference. Either way, I Kudoed both ideas. I'm mainly cross-referencing for the sake of the 3-month old idea... it did not get NEARLY as much Kudos as it deserves, and hopefully some of the post-NI Week craze will go back and read the old posts. So, all of you who like this idea, please go back and check out Paul's New Decor.
Message Edited by JackDunaway (mechelecengr) on 09-01-2009 11:35 PM
I like this idea, but what happens when you have (for example) two or more Vertical Smooth Box? I think NI would have to allow labels on decorations for this idea to be fully realized, or maybe we could do it with tags.
NI needs to spend resources on improving the user interface and reducing the hoops the programmer has to go through to fight with LabVIEW to make the front panels look decent. Hopefully the overwhelmingly positive response at NI Week to just minor improvements to the UI look and feel (even if just in keynote demonstrations) will open NI's eyes to how much LabVIEW lacks in the UI development area compared to other coding environments.
I like this idea, but what happens when you have
(for example) two or more Vertical Smooth Box? I think NI would have to
allow labels on decorations for this idea to be fully realized, or
maybe we could do it with tags.
In your example, if there are 2 (or more) vertical smooth box, I will edit the BD label of the reference decoration and give each one a different name (like I would do if I were to do the same thing with two control having the same name).
Note: It is already possible to edit explicit control reference labels.
So, I don't think there is a need for decoration to have labels.
I was about to add this myself and then I saw your post. I really like it. It doesn't seem like it should be that hard to implement. Then again I don't really know what goes on behind the scenes.
Sam Taggart CLA, CPI, CTD, LabVIEW Champion DQMH Trusted Advisor Read about my thoughts on Software Development at sasworkshops.com/blog
That old, and no solution. In principle you can access the decorations property. BUT when changing the order on the front panel one will loose the specific decoration one wants to access. And what happens if one wants to make a decoration as type-def (if that is possible)?
My suggestion - if this is important to you today, customize a control (usually a boolean will do) and replace its graphic parts with that of the decoration. Then you can create an explicit reference and make it a typedef.
As suggest earlier, you can also create a psuedo-reference today using tags. There's a JKI RCF plugin which does this in the communities (that plugin is probably what PJM was referring to when he said Ton gave him the idea), but you will have to adapt it if you don't have the RCF. I would suggest going with the control.
Is there a valid and logical reason why we are unable to create a static reference to a decoration if the refnum can already be found indirectly via vi property nodes?