Leaderboard

The Project Provider Framework is an API provided by LabVIEW that has minimal support from NI. This API can be used to create new types of project items, add new menu items, and other stuff like that. They only share documentation about the API with those who apply to be partners, however, and there is a signature mechanism to enforce this. Well I've figured out how that signature is generated, so hopefully the LAVA community can do some cool stuff with this! I haven't really played around with it at all, but I plan to. Each plugin is defined by an INI file, located in resource\Framework\Providers\GProviders. Each INI file has a Signature key, which is required to be valid in order for LabVIEW to load the plugin. To generate this signature, first you need to concatenate all the values (not the keys) in the INI file. Only string values though, not numeric or Boolean ones. I'll use GOOP_MyComputer.ini from OpenGDS as an example: [Provider] SupportedType={CEFE1B10-1732-4678-A70A-299293455410} IsPrimary=0 ItemInterfaceVI=..\Open_GDS\GOOP_MyComputer_Item_Interface.vi CreateNewWizardInterfaceVI=..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.vi CreateNewWizardHost=Source LicenseName=None InterfaceVersion=1.0 Signature=KS5CBT93T9SSJK3SNWB239RLN95WTC9W Ignore the Signature line as well, of course. The concatenated string here will be "{CEFE1B10-1732-4678-A70A-299293455410}..\Open_GDS\GOOP_MyComputer_Item_Interface.vi..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.viSourceNone1.0". Take the MD5 hash of this string. In this case, the hash is "8423091770884C816AF971DB7A632067". The next step is to apply a simple substitution cipher to the MD5 hash: 0123456789ABCDEF T3C5K7W9SBNRJLX2 Just replace the character on the top with the one under it. So the new string will be "SKC5TB399TSSKJS3WN2B93LR9NW5CTW9". One more step! For each pair of characters, i.e. "SK", "C5", "TB", ..., switch the two characters. In this case you'll have "KS5CBT93T9SSJK3SNWB239RLN95WTC9W". And look! That's the signature in the INI file! I've attached a VI that does this for you, minus the step of concatenating the INI values. Just pass the VI a string and it will output the signature. Enjoy, but keep in mind the usual warning about using unreleased features of LabVIEW: don't use it for anything too high-stakes. Generate PPF Signature.vi EDIT: To make this process easier, I have also written a C# program that will automatically sign an INI file for you. Just drag and drop the INI file onto the EXE, or use the command line to specify an output filename as well. Both the source code and EXE are included here. SignPPFPlugin.zip Also, here's some palette files for the PPF's API VI's. Since they won't all fit on one page, I did some very simple categorization, simply creating separate menus for "Get" functions, "Set" functions, and one for all the others. Extract the ZIP file to menus\Categories\Addons, and then just put it in your palette from the palette editor. PPF Menus.zip Finally, here's a tool that will automatically generate the interface VI's for you. I found it annoying to always have to update them. Basically they're just VI's that output a cluster with a bunch of paths to "method VI's", which are basically the PPF equivalent to XNode ability VI's. So this will just search for method VI's in the same folder, and generate an interface VI for you through scripting. I called it "PPF Assistant" in case I ever decide to add stuff to it for other PPF-related tasks. This requires OpenG, as well as gb119's Scripting Tools. PPF Assistant.zip EDIT2: Looks like the PPF was recently officially made public (though still not supported) including NI's official INI signing tool. Glad my thread here could be of assistance to the people having trouble with that tool!

Lots of my code has a developer it's ashamed of.....

But.... If I ignore what everyone says, then I must also ignore what you say..... D'oh, what to do? Coffee.

I don't mean to be that guy, but I think creating an express VI would get you half-way there. Express VIs can go on the palettes and can contain any code. Once you drop one down, you can right click and select "open front panel", and it will prompt you to convert the VI from an express Vi into a normal VI. You can then save this converted express VI and boom, you have your desired outcome. Negatives that I am aware of: -Your code starts out in humongous express vi form (rather than as an icon). -Your code would, technically, be an express vi. That having been said, if this is a common use case for you I think making some sort of tool would be the cleaner way of doing it.

I think his goal is to drop a VI onto the block diagram and have it be created as a new, unsaved VI that already contains some code, similar to what happens when you select some code and do Create SubVI. I can see why this might be neat, but I don't know how you would achieve it.

The rules are simple C programming rules. If you pass an array of handles to C code and resize the array size, you are fully responsible to deallocate any elements that are occupied by the previous array beyond its new size and to allocate any elements thathaven't existed before in the array. Additionally you have to make sure to resize any existing handle to the required size before you modify its contents. And your last remark about that who allocated it also needs to deallocate it, that is ambiguous at least. In C the caller is usually responsible for both since there is no standrad way of passing ownership of memory between caller and callee, but APIs can decide to change that, by allocating and returning memory, but that has to be specifically documented by the API and such an API better provides a function to allow the caller to deallocate that memory later on, since the malloc/free from the API may not be compatible and not even refer to the same heap than the malloc/free of the caller. In LabVIEW the situation is different. LabVIEW uses a standardized memory manager throughout, so this limitation does not exist. Whoever holds onto a handle is responsible to manage and eventually release it and all of its contents. For a C function being called by LabVIEW with native handles, this means you may get in a handle, you may modify it and allocate/deallocate any handles therein, provided you also keep the related information such as the array size consistent. If you then pass the array back (which you basically always do if it is in a value parameter, and usually also if it is a reference parameter, you pass on ownership of that handle back to LabVIEW and it will need to manage it from thereon. An additional tidbit you should know is that LabVIEW uses for performance reasons often a null handle when an empty handle is required, but treats an empty handle also correctly. So your C code needs to be prepared to handle an array of 1000 empty strings to be really an array of 1000 null handles, meaning when you want to write something into these strings you can not just do a DSSetHandleSize() as that will crash on a null handle. Instead use NumericArrayResize() with element type uB, as this function gets the handle passed by reference and will correctly allocate a new handle if it was null.

I think you're looking for [LabVIEW]\resource\Framework\Providers\LVClassLibrary\CLSUIP_MemberTemplate.vit. I changed the structure in there to not Auto Grow, and my new static/dynamic dispatch VIs no longer had Auto Grow set. -D