Leaderboard

I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible. That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written. So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_> Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.

This works, but I think he'll also have to put Get LV Class Default Value by Name and Get LV Class Path into a SubVI - let's call it Get LV Class Path by Name. He'll then have to open a reference to that VI with the appropriate application reference and do a call by reference. Then he can go crazy with property nodes across application contexts.

FYI, I just ran a quick experiment (see code below). Watching profiler and task manager, it appears the compiler is smart enough not to copy the string.

And here is what the relevant bit of "solved" code looks like. The VI.OwningApp property was the key that I had glanced over and allows opening items from memory by name from the project, which aren't available from the NI.LV.XNode context.

So I definitely need to do some refactoring of my menu generation code to hide the extra intermediate elements but now I can use it for what I was intending!

I think it's extremely useful. I added DVR support to the latest version of LV-Signals which does something very similar: It only works with DVRs of clusters, and it looks like yours works with DVRs in general. Check out LV-Signals if you get a chance, the original use was to use it with LV-Create-Signals.xnode, which creates a DVR and a value change event for each element in the cluster. https://github.com/erdosmiller/lv-signals

Given your other post is it safe to assume this is an xnode? In that case, maybe you can use this https://lavag.org/topic/19781-xnode-owning-diagram/ to get a ref to the VI you're dropping on and then use that vi ref to get the application context and from there go crazy with property nodes across application contexts?

It's the thing you point to when someone says they've found a bug

So in a presentation about XNodes I was asked a question about what were the valid "Reply" options for an XNode ability. Some abilities have a reply as a 1D array of string and it appears to work like a QMH where you provide a list of states to go to and it does them one after another. I didn't know the answer but I knew scripting could help. So I scanned a bunch of XNodes for what strings were on the block diagram going to the reply and here are the abilities, along with the reply strings I've seen used. AdaptToInputs UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs Copy GenerateCode UpdateTerms UpdateImageAndBounds FailTransaction DoubleClick FailTransaction UpdateTerms UpdateImageAndBounds GenerateCode GenerateCode PreserveUserCodeGUID GetError Message UpdateTerms UpdateImageAndBounds GenerateCode FailTransaction ForceAdaptToInputs OnFontChange UpdateImageAndBounds UpdateTerms OnOperateClick UpdateImageAndBounds GenerateCode OnResize UpdateTerms UpdateImageAndBounds GenerateCode OnDrop UpdateTerms UpdateImageAndBounds GenerateCode OperateClick ShowMenu RefeeChanged GenerateCode UpdateImageAndBounds UpdateTerms RespondToDrop GenerateCode UpdateTerms UpdateImageAndBounds SelectMenu UpdateImageAndBounds UpdateTerms GenerateCode FailTransaction ReplaceSelf Size UpdateImageAndBounds UpdateTerms GenerateCode UpdateState GenerateCode ForceAdaptToInputs IssueWarning UpdateStateWithRef UpdateImageAndBounds UpdateTerms GenerateCode ReplaceSelf So the unique values that I've seen put into the Reply are the following. I am unsure if only some abilities only support some replies. UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs FailTransaction PreserverUserCodeGUID GetError ShowMenu ReplaceSelf IssueWarning As for what do these do? Well some are more obvious than others, but here is some text I found in one of the XNodes that helps: FailTransaction: LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel. GenerateCode: This will cause a type propagation if appropriate, and will cause the XNode to GenerateCode when type propagation is run. UpdateImage: LabVIEW will call Image and invalidate the XNode. UpdateImageAndBounds: LabVIEW will call Bounds and Image and resize and invalidate the XNode. It will not call Size. Size is only called if the user resizes the XNode (so that you may update your state and return this reply). Make sure that if your terminals need to change size or location, you also return UpdateTerms. This reply will set the transaction type. UpdateTerms: LabVIEW will call Terms and create, delete, and move terms as necessary. ForceAdaptToInput When mutating an old, unconfigured Express VI, we need to ForceAdaptToInputs before code gets generated. AdaptToInputs used to always get called before GenerateCode. But that is no longer the case in LV2011.