Jump to content

XNode Editor


Recommended Posts

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.

Link to comment

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"
Link to comment
  • 1 month later...

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.)

Link to comment

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.

Link to comment

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.

Link to comment
  • 4 months later...
  • 2 weeks later...

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.

Link to comment
  • 3 months later...

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.