LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Static Decoration Reference XNode

Many times I've wanted to manipulate a particular decoration; but getting to it has always been messy.  Now I've finally made an XNode that pushes the messiness under the hood.  Just drop 'Decoration Reference.xnode' on your block diagram, then use the 'Operate' tool to pick a decoration, or right-click and select 'Link to ...'.  Note that in the 'Link to' dialog you can slow-double-click on the 'Decor Label' column and change the label* of a decoration,

Sorry, it can't link to decorations inside clusters.

 

* Well, it's not a real label, but that's what I call it.

"If you weren't supposed to push it, it wouldn't be a button."
Message 1 of 10
(1,532 Views)

 

Nice !

I can't understand why NI hasn't implemented this ages ago !

 

Here are some improvement ideas:

 

1. A better "operate-click" menu selection by reorganizing submenus:

 - 1st group with "labelled" decorations sorted alphabetically (format: "%label")

 - 2nd group with "unlabelled" decorations sorted by descending UID (format: "Text "%abbrev_text"" for Texts and "Decoration %UID" for others).

Descending order is preferred because it would put recently created decos at the top of the group. Also use directly the Pane label to match the behaviour of the standard VI Server Reference selector:

 

raphschru_0-1627075481542.png

 

2. Add a "Link to selected decoration" function in the right-click menu. It would directly link to the decoration currently selected on the FP.

An even better (but quite harder) way of doing this would be to allow the user to drag and drop any object to the xnode to make the link (This could also be useful for scripting by allowing references to BD objects!).

 

3. Either the xnode label could be unmodifiable to always match the linked deco, or the deco name could be written inside the xnode directly (instead of just "Decoration"):

 

raphschru_1-1627075492192.png

 

 

Some bugs I discovered:

 

1. Linking seems to be made from the decoration index instead of its UID, so it gets messed up when adding/removing decorations.

Consequently, xnodes linked to deleted decorations should either be deleted at the same time (like standard VI Server Reference selector) or simply output an invalid refnum at run-time.

 

2. When cancelling the "Link to..." dialog with the exit cross, everything is frozen and you must kill LV.

 

3. When double-clicking to highlight the deco (either from the xnode or from the dialog box), you should clear the previous FP selection before selecting the decoration to avoid selecting both (like standard VI Server Reference selector).

 

 

Could you share your xnode project ? I always wanted to learn how to do them. And now with NXG cancelled it seems they may stay here for a long time 😁.

0 Kudos
Message 2 of 10
(1,449 Views)

@raphschru wrote:

 

Nice !

I can't understand why NI hasn't implemented this ages ago !

 

Here are some improvement ideas:

 

1. A better "operate-click" menu selection by reorganizing submenus:

 - 1st group with "labelled" decorations sorted alphabetically (format: "%label")

 - 2nd group with "unlabelled" decorations sorted by descending UID (format: "Text "%abbrev_text"" for Texts and "Decoration %UID" for others).

Descending order is preferred because it would put recently created decos at the top of the group. Also use directly the Pane label to match the behaviour of the standard VI Server Reference selector:

 

raphschru_0-1627075481542.png

 

2. Add a "Link to selected decoration" function in the right-click menu. It would directly link to the decoration currently selected on the FP.

An even better (but quite harder) way of doing this would be to allow the user to drag and drop any object to the xnode to make the link (This could also be useful for scripting by allowing references to BD objects!).

 

3. Either the xnode label could be unmodifiable to always match the linked deco, or the deco name could be written inside the xnode directly (instead of just "Decoration"):

 

raphschru_1-1627075492192.png

 

 

Some bugs I discovered:

 

1. Linking seems to be made from the decoration index instead of its UID, so it gets messed up when adding/removing decorations.

Consequently, xnodes linked to deleted decorations should either be deleted at the same time (like standard VI Server Reference selector) or simply output an invalid refnum at run-time.

 

2. When cancelling the "Link to..." dialog with the exit cross, everything is frozen and you must kill LV.

 

3. When double-clicking to highlight the deco (either from the xnode or from the dialog box), you should clear the previous FP selection before selecting the decoration to avoid selecting both (like standard VI Server Reference selector).

 

 

Could you share your xnode project ? I always wanted to learn how to do them. And now with NXG cancelled it seems they may stay here for a long time 😁.


Thanks for the feedback.  I'll look into those things when I have a chance.

There is no project.  The .zip file contains everything.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 10
(1,445 Views)

Improvements:

  1. Done.  Slightly differently though,
  2. Done.
  3. Not done.  Labels are editable by design.

 

Bugs:

  1. I can't reproduce the linking getting mixed up.  Can you provide a sequence to reproduce it.  Regarding deleted labels: There's no way for an XNode to know when a decoration gets deleted.
  2. Fixed.

 

"If you weren't supposed to push it, it wouldn't be a button."
Message 4 of 10
(1,394 Views)

The mixing up is simple to reproduce:

1. Drop a decoration on the FP;

2. Drop your xnode on the BD, link it to the decoration;

3. Duplicate the decoration on the FP with ctrl-drag;

4. Click "Find Decoration", the xnode is now linked to the duplicated decoration instead of the original.

 

Another sequence that causes a runtime error inside the xnode:

1. Drop a decoration on the FP;

2. Drop your xnode on the BD, link it to the decoration;

3. Drop a second decoration on the FP (without copying the first one);

4. Run the VI -> error inside the xnode

 

Another sequence that causes a visual glitch:

1. Drop a free label "Text1" on the FP;

2. Drop your xnode on the BD, link it to Text1;

3. Either change the xnode label or the text in the free label to e.g. "NewText";

4. Reselect the decoration through the operate menu -> label is flickering.

 

I noticed you removed the "edit names" dialog and use now the xnode label to set the actual name of the decoration. That's clever, but what if several xnodes are linked to the same decoration and we change the label on one of the xnodes ? The other are not updated...

 

By the way I noticed an ability called "OnRefeeChange" that could potentially allow the xnode to be notified when the linked decoration is deleted. The help says it requires to call the "methods available on the XRef". How do you do that ? In my environment, the XNode class have no visible method or preoperties, I have to cast it to a regular "Node", even with all the private ini keys. How did you access them ?

0 Kudos
Message 5 of 10
(1,364 Views)

@raphschru wrote:

The mixing up is simple to reproduce:

1. Drop a decoration on the FP;

2. Drop your xnode on the BD, link it to the decoration;

3. Duplicate the decoration on the FP with ctrl-drag;

4. Click "Find Decoration", the xnode is now linked to the duplicated decoration instead of the original.

 

Another sequence that causes a runtime error inside the xnode:

1. Drop a decoration on the FP;

2. Drop your xnode on the BD, link it to the decoration;

3. Drop a second decoration on the FP (without copying the first one);

4. Run the VI -> error inside the xnode

 

Another sequence that causes a visual glitch:

1. Drop a free label "Text1" on the FP;

2. Drop your xnode on the BD, link it to Text1;

3. Either change the xnode label or the text in the free label to e.g. "NewText";

4. Reselect the decoration through the operate menu -> label is flickering.

 

I noticed you removed the "edit names" dialog and use now the xnode label to set the actual name of the decoration. That's clever, but what if several xnodes are linked to the same decoration and we change the label on one of the xnodes ? The other are not updated...

 

By the way I noticed an ability called "OnRefeeChange" that could potentially allow the xnode to be notified when the linked decoration is deleted. The help says it requires to call the "methods available on the XRef". How do you do that ? In my environment, the XNode class have no visible method or preoperties, I have to cast it to a regular "Node", even with all the private ini keys. How did you access them ?


Many fixups in this new version.

Unfortunately "OnRefeeChange" doesn't catch decoration deletions.

Normal access to XNode properties and methods requires a license that NI doesn't share.  Attached is a VI with all XNode properties and methods.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 10
(1,340 Views)

@raphschru wrote:

 

How do you do that ? In my environment, the XNode class have no visible method or preoperties, I have to cast it to a regular "Node", even with all the private ini keys. How did you access them ?


It is an undocumented technology that NI would rather, non NI developers not use.  That being said it can do things that no other LabVIEW technology can do.  I presented on it years ago giving some tools to help develop XNodes.

0 Kudos
Message 7 of 10
(1,333 Views)

@Hooovahh wrote:

 

It is an undocumented technology that NI would rather, non NI developers not use.  That being said it can do things that no other LabVIEW technology can do.  I presented on it years ago giving some tools to help develop XNodes.

I know 😁 I've watched it several times, when nothing is documented, it's like a gold mine to find this (I used this better-quality video of your presentation https://www.youtube.com/watch?v=R2En7yMANi8)

 

I'm also currently using your XNode Editor (1.1.0), that's a good start to learn XNodes !

Have you made another version since ? While developping my first XNode, I encountered some errors that I think could be corrected (also some improvement ideas maybe...).

0 Kudos
Message 8 of 10
(1,324 Views)

@raphschru wrote:

I'm also currently using your XNode Editor (1.1.0), that's a good start to learn XNodes !

Have you made another version since ? While developping my first XNode, I encountered some errors that I think could be corrected (also some improvement ideas maybe...).


Nope, I've been pretty lazy lately and haven't made any XNodes but love watching Paul and others come up with cool stuff.  I also looked into automating the activation of the XNode license, and that didn't get very far since to make it work it would rely on several tools, and things that could enable piracy.  The source to the XNode Editor is on LAVA so you are welcome to make changes and post them there.

0 Kudos
Message 9 of 10
(1,314 Views)

@raphschru wrote:

@Hooovahh wrote:

 

It is an undocumented technology that NI would rather, non NI developers not use.  That being said it can do things that no other LabVIEW technology can do.  I presented on it years ago giving some tools to help develop XNodes.

I know 😁 I've watched it several times, when nothing is documented, it's like a gold mine to find this (I used this better-quality video of your presentation https://www.youtube.com/watch?v=R2En7yMANi8)

 

I'm also currently using your XNode Editor (1.1.0), that's a good start to learn XNodes !

Have you made another version since ? While developping my first XNode, I encountered some errors that I think could be corrected (also some improvement ideas maybe...).


Use caution. Simple mistakes can create great havoc.  Consider this worst-case scenario:
You develop an XNode and test it thoroughly. It works fine. You start using it; in many places.
Later on, you make a minor update to the XNode; but you have an error in your update code (this could be as minor as a typo).
You test the new version and it works fine.  You recompile all the old code that uses the XNode. You thoroughly test all that old code. It works fine.
At some later date (maybe much later), that old code (that originally used the 1st version of the XNode) starts breaking; or worse yet, doesn't break, just behaves incorrectly.  And the trigger for the breakage could be something as trivial as just moving the mouse over the XNode.  Have fun trying to find that bug!

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 10 of 10
(1,298 Views)