Jump to content

Don't Put Malleable VIs Inside XNodes


Recommended Posts

If you have a malleable VI (.vim) inside an XNode,

and an instance of that .vim has a declined frame of a type specialization structure,

and inside that declined frame you call a VI owned by the XNode,

and you have a build spec that copies and renames the XNode,

Then that renamed copy of the XNode will be broken because the item in the declined frame isn't properly linked.

Link to comment

I wouldn't trust a malleable VI inside an XNode at all without extensive testing. XNodes are unsupported tech when used for general purpose problem solving. Although I did do some light testing of the interaction between the two technologies a couple years ago, I did not vet their interaction fully. When NI writes an XNode, we don't assume that "XNode" is a safe tech to use... we vet the specific XNode that we are writing, checking its correctness and stability under its various scenarios. None of our shipping XNodes have used VIMs.

You may have success using the two together, but I'd advise you to be careful. You have a tech (malleable VIs) that decides its internal types at caller's semantic analysis timeĀ  (i.e. every mouse click) lodged inside a tech (XNodes) that decides its types only at caller's compile time (i.e. when you click the run button). The malleables may not be happy having their type computations deferred.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.