Leaderboard

I think you can! It looks like the compiler exception doesn't check the fully qualified name. You can put your inline-safe XNodes inside libraries to namespace them, and name them all Error Ring.xnode.

PS: what you lost from the XNode implementation you gained in performance and not randomly crashing! :-)

The convert to standard is the only mechanism. I have intentions of opening up the instance VI, but I've run into some *fascinating* historical code... malleables will get a nice power kick in 2017 SP1 and some potent assist features in 2018, but opening the instance won't be in 2018 at this rate (seeing as how I need to be feature complete on the 18th). In the meantime, convert to standard and then hit ctrl+z to put the malleable back. Suboptimal but it does work.

I think you could do this by modifying <LabVIEW>\resource\plugins\lv_new.vi I'm telling you how to cut into LabVIEW's internal operations. If you break that VI, you could lose functionality you care about. Make a backup copy first.

I think there is just a special case that LabVIEW knows the XNode named "Error Ring.xnode" can be inlined. If I rename an XNode to Error Ring.xnode, the aforementioned error goes away. I wonder if there is a way to whitelist other XNodes.

In LabVIEW 2017, there is the Malleable VI (vim). This will adapt to the input type. In previous versions, this was a hidden feature called "macros".