Contestant Info:
Contact: Erik Johnson erik.johnson@ni.com 408.234.7569 | |
Meeting Details: Quarterly meetings, Tuesdays from 5:45 - 8:30 p.m. | |
User Group Website: http://decibel.ni.com/content/groups/bay-area-labview-user-group |
You spend a lot of effort getting your block diagram looking its finest, and now it is time to document your code. Nothing spoils the Feng Shui quite like the old flat frame and free label. It is about time that we had a few new tools, and here I give an example of two I’d like to see: a nice rectangle with an embedded label (XBox), and an active hyperlink for the Block Diagram. Should someone RTFM? Now you can link to it directly on the diagram, no more walls of text, or copy and pasting.
The power behind these tools are once again XNodes. Wait? Don’t you need to be a scripting and LabVIEW ninja just to think about using these? It helps, but these two XNodes are examples of extremely useful things you could do without any scripting whatsoever. If I am not kicked off the island too early, you too will be able to explore their power as I will unlock their mysteries as the rounds progress. XNodes are basically like XControls for your BD. You create “abilities” in the form of VIs,each of which performs a specific function. Unlike normal subVIs, XNodes can be resized, have active behaviors during edit time, and can adapt on the fly to different datatypes. Handling all of these behaviors does require some scripting knowledge, but for now, let’s explore some XNodes which only handle a few functions: Responding to clicks, editing a text field, and resizing.
Function:
The first XNode is the Hyperlink.xnode, this will place an active hyperlink on the BD. This can be a website, or a file on the local harddrive (PDF, Word Document..). During edit time, clicking on the link with the operating tool (pointing finger) launches the appropriate program, and the text tool allows you to edit the link. When running, or in run mode, a double click is required to activate the link (XNodes do not respond to operating clicks in run mode). This is a great way to add references, either to the forum post you are responding to, the source of the algorithm you are implementing, or the instrument manual.
The second XNode is the XBox (XNode + Box), this will draw a rounded rectangle with an embedded label. The label is kept centered as the rectangle is resized. A double click in the label bar opens a GUI to change colors as well as text properties. Document code segments, flag bugs and errors, or just add review comments. Two minor issues: BD cleanup will move code outside the rect, and created constants and controls are also placed outside. This is really a proof-of-concept, and is also meant for documenting code so not that big of a deal. Besides, the LV flat frame also suffers from these "features" (hmm…, I wonder how they are implementing those?).
Screenshots:
Here is an example block diagram with added comments and a hyperlink:
When you double click on the label bars, you will see this UI to change properties of the XBox:
Each folder has a XNodeName_Tree.vi which is not to be run, but instead shows the various ability Vis arranged to demonstrate the flow of calls during the life of the XNode. As you see, each ability VI is pretty simple, and they are called in a fairly logical order. These Tree VIs make it easy to save to different versions.
Here is a screenshot of the Hyperlink_Tree.vi.
Not really appropriate for this type of code, but stay tuned for future rounds.
Teaser:
Plans for future rounds include adding some capabilities to these XNodes as well as providing the means to explore on your own.
Seems intresting, Darin! Really a Nice one! This would be very helpful for lots of us in our projects....Thanks for this one!
Hi Darin!
I like the idea of some new prettier "decoration items" on BDs as the inbuilt ones are a bit oldfashioned as the case with many UI elements in LV. There has been many conversations here in user groups as well about old-looking UIs, but I've never seen this mentioned about BDs.
There is however something I noticed with the Xnodes you made: if I put them on a BD, and build an exe, the exe will be larger than without the Xnodes. So it seems that these kind of decoration/documentation elements are not stripped out fully from the code. Inbuilt decoration elements however do not get into the exe.
Peter
Peter, Thanks for the info, these guys are hot off the presses so I haven't checked a lot of corner cases. I would have assumed they would be stripped, but I guess not. I'll probably explore that a bit. One of my current projects is to add a menu to the XBox, and specifically add the option to flatten to a PNG object. This would make the final VI portable, and hopefully the image would be stripped in exe's as well.
No guarantees I will pull it off, but I am doing this for fun, and it wouldn't be that much fun if I knew for certain it could be done....
...the XBox (XNode + Box),
Being cute, are we?
As I was writing the code I was in total geek mode and called it 'Labelled Rect'. I then generated the code for all of the different LV Versions. As I was generating this submission page the spell check of MS word flagged the misspelling of 'Labelled'. No way I was going to change everything for that small mistake. Then I shifted into marketing mode from geek mode, and decided that changing to 'XBox' was worth the effort. Of course now I find out that labelled versus labeled is a Queen's English versus American English thing, and they are both right.
I'll keep the new name for now, the conspiracy theorist in me notes that a Bill Gates product has driven me to copyright infringement of another Bill Gates product.
This looks very good!
I am impressed by the possibilities of the documentation style.
Is there a specific reason that there are different versions of the zip-file for each LabVIEW version?
Thanks Ton, Given the lack of scripting (so far) and the fact I do not use any XNode abilities that are incompatible with LV8.6 all I have really done so far is save you the trouble of mass compiling for different versions. An XNode from a previous version will work, it just recompiles every time it gets dropped. With my Math Node, this was very noticable, here not so much, but I still want it to be as easy as possible.
I would have posted packages as well but VIPM wouldn't let me add XNode files to a palette.
One thing I noticed is that a for-loop inside the documentation XNode reverts it's color.
Ah, the old "floating" object shadow, interesting effect, but not a particularly good look. I do like the look when the For Loop is autosized around the label. I guess the first solution is to move the label to the back, and I hope when I perfect the flatten to image step it should be taken care of.
NI won't need to implement all the ideas for "managing comments" on the idea exchange. They are just going to grab what you have developed . That said, if they don't, I am. I never even knew about xnodes until seeing this, but now that I do, maybe I'll set up my own comment schema, linking between comments and different parts of the code via mouse clicks. Nerd fun, woohoo!
Way cool Darin!
I can see uses in a couple of current projects and extensions ideas. This could be the basis for a "requirements tracking lite" package, with the links as file hyperlinks, with target numbers leading to the specific Requirements number the code snippent is implementing, in the hyperlinked doc. I can also see adding a Notes item to the XBox to embed documentation, etc.
Couple of questions. I got absolute file hyperlinks to work with .chm files but must be doing something wrong on relative links. How do we do a link to a relative file?
I am new to XNodes. What do we have to have, LabVIEW license wise to create and edit them?
Thanks! Looking forward to the later rounds!
Thanks. When I posted this I mistakenly thought that future rounds would be to extend this program, but they chose to assign us homework instead.
I still hope to grow this example a bit when the dust settles. Right now my use of XNodes is completely hack based and creating new ones requires some private functionality. What I will provide eventually in this example is a template XNode with the common abilities that cover most cases. That combined with the knowledge of the tasks each ability provides goes a long ways.
Relative links will be added as well, in the click handling abilities I simply check for a relative path and add the owning VI path as necessary. I also will add the ability to decouple the link text from the actual URL. I'll try to get that posted soon, if I play with it too much now I won't have time for the challenge!