lordexod Posted July 1, 2015 Report Share Posted July 1, 2015 Works without xnode license. XNode.zip 1 Link to comment
hooovahh Posted July 1, 2015 Author Report Share Posted July 1, 2015 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
JackDunaway Posted July 3, 2015 Report Share Posted July 3, 2015 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
lordexod Posted July 3, 2015 Report Share Posted July 3, 2015 These are correct.XNodeAbilities.txt Link to comment
ShaunR Posted July 4, 2015 Report Share Posted July 4, 2015 (edited) Aren't all the supported (for that version) xnode methods in "resource\Framework\Providers\xi\xnode.llb"? Edited July 4, 2015 by ShaunR 1 Link to comment
lordexod Posted July 4, 2015 Report Share Posted July 4, 2015 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. Link to comment
Sparkette Posted August 13, 2015 Report Share Posted August 13, 2015 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
hooovahh Posted August 13, 2015 Author Report Share Posted August 13, 2015 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
Sparkette Posted August 13, 2015 Report Share Posted August 13, 2015 I thought the PPF let you create new types of items that can appear in projects too. Link to comment
hooovahh Posted August 14, 2015 Author Report Share Posted August 14, 2015 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
Popular Post hooovahh Posted January 4, 2016 Author Popular Post Report Share Posted January 4, 2016 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 3 Link to comment
pawhan11 Posted January 18, 2016 Report Share Posted January 18, 2016 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. Link to comment
hooovahh Posted January 19, 2016 Author Report Share Posted January 19, 2016 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
lordexod Posted May 11, 2016 Report Share Posted May 11, 2016 Simpler XNode . XMacro.zip Link to comment
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now