Load Project Programmatically Without Suppressing Load Conflicts

[jon_mcbee]

I have the need to programmatically load a project with known load conflicts (i.e. dependencies will not be at the expected location) and I would like LabVIEW to prompt the user to navigate to the appropriate locations on disk for each dependency.  When I open the project through the Windows file explorer I get the expected load conflicts popup messages, however when I open the project programmatically via invoke nodes those load conflict popup messages are suppressed.  Does anyone know of a way to open the project programmatically without suppressing this load conflict dialogs?

I'm happy to discuss WHY I want to do it this way, but really just need a go or no-go from NI on if there is a special method I can use to open a project without suppressing these dialogs.

[Kyle97330]

What about using the system exec function to open it as if it was double-clicked on?

[jon_mcbee]

That definitely gives me the behavior I need, I bet I could hack a solution together based on this concept and monitoring active projects in the application instance.  High level I am putting together a tool that can clone a git repository, pull submodules, and build the submodule PPLs in the correct order.  I'm in good shape outside of submodule projects not being able to source their dependent PPLs on first open.

What I really want, I guess, is a way to programmatically open a project while specifying paths to dependencies not in vi.lib as a way to preempt the load conflicts altogether.  

Anyhow, thanks for the thought.

[Darren]

Instead of opening the project, you could parse its XML and look for things that aren't in the expected locations, then programmatically modify the XML (via prompting the user for the correct paths I guess?) before actually opening the project.

[raphschru]

Hi,

You can specify search paths to help LabVIEW find missing dependencies when opening the project, by using the private property "Search Paths":

But I don't really understand why you would have load conflicts in the first place.

If there is a conflict, it means the PPLs are missing, so how could the user select where they are? Did the PPLs' location change?

Or maybe you just want a list of support PPLs of a given project in order to also clone and build the PPLs' subprojects?

The ProjectItem class has a "Find Missing Items" property:

Also, the simplest solution might even be to simply not load the project with VI Server and read the lvproj as an plain xml file and collect all project items whose path have the extension ".lvlibp".

Regards,

Raphaël.

[jon_mcbee]

Interesting idea!  It looks like the paths are relative to the project file, but that there are no issues using file paths a few level above the project file:

<Item Name="ppls" Type="Folder">
			<Item Name="Actor Framework.lvlibp" Type="LVLibp" URL="../../../ppls/actor-framework/Actor Framework.lvlibp">
				<Item Name="Messages" Type="Folder">
					<Item Name="Message.lvclass" Type="LVClass" URL="../../../ppls/actor-framework/Actor Framework.lvlibp/Message/Message.lvclass"/>
					<Item Name="Stop Msg.lvclass" Type="LVClass" URL="../../../ppls/actor-framework/Actor Framework.lvlibp/Stop Msg/Stop Msg.lvclass"/>
					<Item Name="Last Ack.lvclass" Type="LVClass" URL="../../../ppls/actor-framework/Actor Framework.lvlibp/LastAck/Last Ack.lvclass"/>
					<Item Name="Launch Nested Actor Msg.lvclass" Type="LVClass" URL="../../../ppls/actor-framework/Actor Framework.lvlibp/Launch Nested Actor Msg/Launch Nested Actor Msg.lvclass"/>
				</Item>

I will play with this approach and see if I can load and build PPLs after modifying the project XML.  Gracias!

[jon_mcbee]

Correct, the PPLs are in a different location than the top level project expects.  This is artifact of how I am using git submodules + PPLs as an internal package management system that allows consuming projects to depend on whatever released version of a dependency that they want.

I played with the app search paths and it did not seem to help LabVIEW locate my PPL when loading a project that has the PPL as a dependency.