Xnode - OnDrop Ability not working in Merge VI

[bbean]

I created an Xnode that pops up a dialog when the user drops it on the block diagram for configuration.  However, when I put the Xnode inside a Merge VI (so I can add it to a function palette menu), the On Drop Ability doesn't fire when the merge VI is used.  I guess this is because its not really dropped but merged.

Is there another ability that will handle this situation in a Merge VI? Couldn't find an OnMerge ability  so  I tried using "On Owner Change" ability, but it fires anytime you put code around the xnode (like a case structure, etc) or copy it to another diagram which could make the popup dialog very annoying quickly.

On a separate note, why can't I add an Xnode directly to a functions palette menu?

[hooovahh]

You actually can put an XNode directly on the palette.  Look at the Add-ons >> Find LabVIEW Add-ons which on first being created will open up a web page.  A fun little trick that you can use to do something to do all sorts of things on first copy.  I have one function that can open a folder to a network location where some specialized documentation is stored.  When you are editing the palette manually, you just need to change the filter on the browse dialog to show all files (*.*) and select an XNode and it works as it should.  

For VIPM there are a few tricks, but the best I've come up with is a using the Post-Install action VI.  In the Post Install you can see what VIs were added to the palette, so I will search for any XNodes, then see if a merge VI was made for that XNode (just the same name but different extension), then read the functions palette, replace the path of the merge VI with the path to the XNode, and then resave the functions palette I opened.  A bit of a pain for sure, but once you have it working the updating or adding new XNodes can be done just by making a merge VI, and adding it to the palette, then the Post Install does the rest.

But for your situation I wonder if the Copy ability will work just as well, where the dialog is seen on the creation of the XNode instance.

[bbean]

Thanks, I'll probably try the Copy ability.  For future reference, can you upload an example Post-Install VI with the actions you described?

Also is there a list anywhere that describes the syntax for "Reply" commands/states in the Xnodes?  For instance, is there a way to force the AdaptToInputs ability.. (UpdateInputs maybe?)

[hooovahh]

Sure thing, attached is my Post-Install.  It will look at all MNU files installed, and look for any files that share the same name as the XNode, and replace them in the palette, with the actual XNode call.  I add a suffix to installed VI files so my Post-Install only looks at the name before the _ suffix, because the suffix isn't added to XNodes by VIPM.  It has a few OpenG dependencies, so if you are making a package be sure and add those to the dependencies list, so that they will be installed before trying to run the Post-Install VI.  Oh and you'll want to open it and resave it, I back saved to 2012 and assume paths to the OpenG library might be messed up.

As for the reply, some of the abilities describe being able to be called, here is the description for the GetTerms4 ability:

Quote

 If you want to update your terminals, you should return the UpdateTerms reply in one of your ability VIs.

But as for a formalized list, I just don't have one.  Here are a few other string values I've seen put into the Reply and have things get called.

UpdateImageAndBounds, UpdateTerms, GenerateCode, Initialize, this list just comes from seeing what others have done.

Post-Install Custom Action Replace XNodes in MNU.vi