XNode Editor

[lordexod]

Works without xnode license.

XNode.zip

[hooovahh]

Works without xnode license.

That's great if you already have an ability made and want to add it.  It also doesn't do things like find the State control type def and replace them.  It also doesn't set the allow run time.  And you need to know the correct name of the Ability.  But still you showed me one step that I could remove, which is when adding the file set the type to Ability VI.

[JackDunaway]

It appears `<vi.lib>:\resource\lvstring.rsc` has not been updated since sometime before LV2014, so for that reason it's not a great "central source of truth" for discovering Abilities. Instead, here's a list that's perhaps a bit more updated, parking here so it's indexed by search engines.

 

This list was generated by simply searching the <labview> directory for all files of type `.xnode`, then using XPath queries to extract all `NI.XItem.Name` abilities. It appears that many of these "correct" names map closely to the stale `lvstring.rsc` names -- for example, it appears that what used to be called "GetImage" is now just called "Image". One important one you'll need: "UpdateState*" is now "UpdateStateWithRef"

 

AdaptToInputs

AugmentSelf

AutotoolRegions

Bounds

BuildMenu

BuildMenu3

BuildMenu4

BuildMenu5

BuildMenuRuntime

BuildPopup

CanAcceptDataDrag

CheckRefeeChange

Compare

Compare2

Copy

DataDrag

DisplayName

DoubleClick

DoubleClickRuntime

ExportStrings

GenerateCode

GetDataForDrag

GetDisplayName2

GetDisplayName3

GetErrors3

GetTerms3

GetTerms4

GrowInfo

Help

HelpMap

Image

ImportStrings

Initialize

L10n

ListErrors

ListErrors2

Message

MessageWithoutEffect

ModifyCode

OnFontChange

OnTextChange

OperateClick

RefeeChanged

ReplaceSelf

RespondToDrop

SelectMenu

SelectMenu3

SelectMenu4

SelectMenu5

SelectMenuRuntime

SelectPopup

Size

SpecifyInsertTerm

State

Terms

Terms2

ToBackgroundForeground

UpdateState

UpdateStateWithRef

 

Additionally, here's the superset of properties used by shipping XNodes (yes, the top "blank" is declared in many shipping XNodes; I think this is just a cosmetic bug, and not meaningful):

 

Name="" Type="Bool"

Name="NI.LV.All.SourceOnly" Type="Bool"

Name="NI.Lib.ContainingLib" Type="Str"

Name="NI.Lib.ContainingLibPath" Type="Str"

Name="NI.Lib.DefaultMenu" Type="Str"

Name="NI.Lib.Description" Type="Str"

Name="NI.Lib.HelpPath" Type="Str"

Name="NI.Lib.HelpTag" Type="Str"

Name="NI.Lib.Icon" Type="Bin"

Name="NI.Lib.Lic.Feature" Type="Str"

Name="NI.Lib.LocalName" Type="Str"

Name="NI.Lib.Locked" Type="Str"

Name="NI.Lib.SourceVersion" Type="Int"

Name="NI.Lib.SynchronizeMNU" Type="Bool"

Name="NI.Lib.Version" Type="Str"

Name="NI.SortType" Type="Int"

Name="NI.XClass.Flags" Type="Int"

Name="NI.XClass.Loc.Name" Type="Str"

Name="NI.XClass.Name" Type="Str"

Name="NI.XItem.ClassId" Type="Str"

Name="NI.XItem.DeclaredLeakProof" Type="Bool"

Name="NI.XItem.Express" Type="Bool"

Name="NI.XItem.InitialDropImage" Type="Bin"

Name="NI.XItem.InitialDropSize" Type="Bin"

Name="NI.XItem.Name" Type="Str"

Name="NI.XItem.StyleName" Type="Str"

Name="NI.XItem.SupportsFatalErrorOut" Type="Bool"

Name="NI.XNode.GCChaining" Type="Bool"

Name="NI.XNode.LazyLoad" Type="Bool"

Name="NI_IconEditor" Type="Str"

[lordexod]

These are correct.
XNodeAbilities.txt

[ShaunR]

Aren't all the supported (for that version) xnode methods in "resource\Framework\Providers\xi\xnode.llb"?

Edited July 4, 2015 by ShaunR

[lordexod]

This is the main layer of native xnode, and everything is supported.

It doesn't mean, that everything must be made available in xnode.llb.

[Sparkette]

The first post I made created the XNode and abilities using scripting.  It would create the XNode, which is a library, then invoke the Add Ability where you specify the ability to add.  Both the Create XNode, and the Add Ability don't work if you don't have a XNode license.  Additionally List Members which usually tells you what items are in a library also doesn't work without a license.

 

So I'm not sure what other scripting functions you could try from the project window.  Just like with adding a VI to a project, you can't invoke a Create VI on a project using scripting.  You first create the VI, then use the Add Item.  And at this point we can't create the item, but we could probably add it if one was made.

 

The only other hope I had was to see if the Project Provider Framework was used to implement the XNode creation in the project window.  It wasn't, that would have been too easy.

 

Just so I'm not completely defeated I figured I could at least post a XNode which has all the abilities on it for a version of LabVIEW.  So if you want a 2013 XNode attached is one that has every ability.  If you don't like the name, you can open the XNode in LabVIEW, and perform a rename which will resave all the members.  That part does work without a license.  To remove an Ability delete the VI, then open the XNode in a text editor, and remove the Item section for that ability.  There are plenty of deprecated abilities that I probably should have included.  Like how Build Menu has 4 older versions when you should probably just use the newest.

 

Maybe you could use the Project Provider Framework for your tool. Does T3C5K7W9SBNRJLX2 ring a bell?

 

(Yes, I do have that memorized.)

[hooovahh]

Maybe you could use the Project Provider Framework for your tool. Does T3C5K7W9SBNRJLX2 ring a bell?

Yes I'm aware of the Project Provider Framework, and actually requested official unofficial access to unofficial documentation (or is it unofficial-official-unofficial?).  I hope I get time to try to make a few things I have thought about.  2015 and right click sparked new interest in it for me  in PPF.

 

But at the end of the day the project provider just gives you a means for running content aware right click menus in the project explorer.  Regardless of where the VIs are ran from, there are plenty of functions that simply return an error of not having a valid XNode license, when you run it on a machine that doesn't have a valid XNode license.

 

Yes there are illegitimate ways of creating XNodes, but if we can demonstrate to NI that the functionality can be exposed in a clever, and more legal means, then maybe that might help convince NI that XNodes can be released.

 

That being said I talked to a couple people at NI R&D about XNodes being released, and the unofficial word is they tried making a push to release it.  But due to the odd licensing scheme used, making XNodes official might never happen.  It sounded like the type of license that is currently being used, cannot be activate through an NI server, without being connected to an NI network.  Which makes me believe that even NI employees can't edit XNodes unless they are connected to the NI domain.  That last part no one stated directly.

[Sparkette]

I thought the PPF let you create new types of items that can appear in projects too.

[hooovahh]

I thought the PPF let you create new types of items that can appear in projects too.

Okay maybe this could be useful if the generation code was stable and works without a license, but I'm still not satisfied with that first step.  If you have code that can generate XNodes, and their abilities, you could invoke it from the project and replicate some of the functionality NI has, but man does that sound like a lot of work.  Besides I also heard that the primary type plugins in the PPF were a bit less stable.  I never heard specifics, but I was told adding new right click items to existing items (like VI types, virtual folder types, etc) should have no problem.

[hooovahh]

I promise I haven't been working on this for over a year.  I just got some new information from someone, on ways to get around the licensing limitation using native LabVIEW code.  I believe I have a proper modern XNode Editor, that will create an XNode, or open an existing one, then allow you to add new abilities.  

 

These abilities are enumerated from LabVIEW, and if new ones are added, the list should show them.  This means it is not version dependent, and shouldn't need updating, just to add new abilities.  It also has a way to change the version, XNode library icon, and description just like the XNode Manager mentioned before.  I haven't fully tested it, but it appears to do what it should.

 

I back saved it to 2012 but I don't have 2012 to test with.

New XNode Editor 2012.zip

[pawhan11]

Thanks for this tool, it works great.

Is there a simple way to make copy of xnode with different name?

So far I have to create methods and copy paste BD code to new ones.

[hooovahh]

Open the XNode in LabVIEW.  Yes double click it.  You can't do much with the library since it is locked having no license, but you can perform a File >> Save As, where you can rename the library, or make a new copy.  Afterwards you click Save All and it will save all the members to use the new library.

[lordexod]

Simpler XNode .

XMacro.zip