LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

Root-level ProjectItem creation and control

I seem to be running into some limitations on the power/control provided by Project Providers, and was hoping someone could help shed some light.

What I'm trying to do:

Create a new "Root-Level" ProjectItem type. The name "root-level" is arbitrary, but it's my attempt to describe a ProjectItem type that behaves more like the Root, My Computer, Dependencies, and Build Specifications (etc...) ProjectItem types, rather than behaving like a VI, LVClass, or other type of project asset. Some features of these 'root-level' Project Items include:

  • implementing the CreateNewWizard interface (this new 'root-level' type would allow children to be created under it) (sidenote: it doesn't actually need to implement the CreateNewWizard interface, since this can be recreated using the Item interface... what's important is the behavior, not the technical means to accomplish the behavior)
  • Maintains a static location in the ProjectTree (for instance, Dependencies then Build Specifications are always the last two Project Items under My Computer -- they cannot be dragged, and nothing can be dragged below them)
  • Has the hooks to interact with and be manipulated by the Project Provider framework

What problems I'm having:

1) I can't create this new type of node programmatically. Here's a smattering of things I've been fiddling with, to no avail:

SmatteringOfNewProjectItemAttempts.png

2) I can create a new item type by editing the LVProj XML in a text editor then opening the LVProj in LabVIEW, but there are several restrictions on where this item can be located, and it's nearly useless. Here are 4 attempts to create a new type, and their results:

Attempt to create a new, regular ol' ProjectItem:

<?xml version='1.0' encoding='UTF-8'?>

<Project Type="Project" LVVersion="12008004">

          <Property Name="NI.LV.All.SourceOnly" Type="Bool">true</Property>

          <Item Name="My Computer" Type="My Computer">

                    <Property Name="specify.custom.address" Type="Bool">false</Property>

                    <Item Name="New Item Type" Type="{DE49108E-3E48-4884-A604-6753D97D88EA}"/>

                    <Item Name="Dependencies" Type="Dependencies"/>

                    <Item Name="Build Specifications" Type="Build"/>

          </Item>

</Project>

Result -- no probs, this ProjectItem can easily be created programmatically and controlled by a Project Provider:

NewItemNoProb.png

Attempt to create the exact same new item, except placing it after Build Specifications:

<?xml version='1.0' encoding='UTF-8'?>

<Project Type="Project" LVVersion="12008004">

          <Property Name="NI.LV.All.SourceOnly" Type="Bool">true</Property>

          <Item Name="My Computer" Type="My Computer">

                    <Property Name="specify.custom.address" Type="Bool">false</Property>

                    <Item Name="Dependencies" Type="Dependencies"/>

                    <Item Name="Build Specifications" Type="Build"/>

                    <Item Name="New Item Type" Type="{DE49108E-3E48-4884-A604-6753D97D88EA}"/>

          </Item>

</Project>

Result -- LVProj file cannot open -- it fails the corruption/validation test that apparently runs before an LVProj is opened:

CorruptLVProj.png

Next try: move this new ProjectItem as a new type under the Root:

<?xml version='1.0' encoding='UTF-8'?>

<Project Type="Project" LVVersion="12008004">

          <Property Name="NI.LV.All.SourceOnly" Type="Bool">true</Property>

          <Item Name="My Computer" Type="My Computer">

                    <Property Name="specify.custom.address" Type="Bool">false</Property>

                    <Item Name="Dependencies" Type="Dependencies"/>

                    <Item Name="Build Specifications" Type="Build"/>

          </Item>

          <Item Name="New Item Type" Type="{DE49108E-3E48-4884-A604-6753D97D88EA}"/>

</Project>

Result -- fails validation:

CorruptLVProj.png

Now, let's keep that item in the same place, but give it a non-GUID Type:

<?xml version='1.0' encoding='UTF-8'?>

<Project Type="Project" LVVersion="12008004">

          <Property Name="NI.LV.All.SourceOnly" Type="Bool">true</Property>

          <Item Name="My Computer" Type="My Computer">

                    <Property Name="specify.custom.address" Type="Bool">false</Property>

                    <Item Name="Dependencies" Type="Dependencies"/>

                    <Item Name="Build Specifications" Type="Build"/>

          </Item>

          <Item Name="New Item Type" Type="aNonGUIDtype"/>

</Project>

Aha! Appears to work -- yet this new ProjectItem Type cannot be controlled by a Project Provider, since it has a non-GUID type, and it appears that the Project Provider INI (the one stored under GProviders) only allows GUID values for SupportedType values:

CloseNoDice.png

The explanation for this new "Unsupported Item" given by clicking that item is:

UnknownItemType.png

So... is it possible to make this item type a "Supported Item"? And/or give it a GUID so that a Project Provider can interact with it? It can be done with NI Hardware Targets -- is this functionality available by a third-party Provider developer?

0 Kudos
Message 1 of 4
(2,753 Views)

Any headway? My instinct (after fiddling around quite a bit now) is that this feature ability goes beyond Project Providers, and must require some additional knowledge/API. Fingers crossed, this additional knowledge/API is plug-in-able, and not hard-coded into LabVIEW....

0 Kudos
Message 2 of 4
(2,711 Views)

Hey Jack,


Sorry for no response.  I was investigating in the background and thought I'd have an answer quicker than I did.  I'm still asking around but so far no luck.  My guess is that this is probably something not available to the standard Project Provider Framework, otherwise we would see more examples of it such as RT or FPGA.  However I'll keep you updated with what we find.


Thanks for your patience,

David

0 Kudos
Message 3 of 4
(2,711 Views)

David_L wrote:

I was investigating in the background

I had no doubts you and the gang were on it like a chicken on a junebug; likewise, was hoping for a 'quick answer', but this is one that I was afraid might not be.... straightforward. 🙂

Let's continue to investigate and look for solutions/alternatives...

0 Kudos
Message 4 of 4
(2,711 Views)