Call VI in EXE but have it execute in Developmen​t Environmen​t not Run Time Engine

Question

I am working on building a palette editor for distribution of a reusable code library for my company (I know the VIPM does this very well already).  I have the code complete and am trying to create an executable that I can distribute that will call the code I wrote to update/create the palette .mnu files for the reuse library, which lives on the company network.  I am using the Palette Editing VI's and it seems as though they cannot be built into an executable.  So I wrote some code to dynamically call my palette modification code (I call it the Reuse Library Manager).  When my executable calls the Reuse Library Manager dynamically I get a broken run arrow on the Reuse Library Manager front panel and the following reasons for the broken arrow:
It seems to me that the reason the Reuse Library Manager works when called in the development environment and not when called dynamically is because the dynamic call uses the run time engine for execution.  This made me think of how in the VIPM it opens LabVIEW while it installs packages.  If anyone knows, does the VIPM open LabVIEW in order to run the Palette Editing VI's or is it for another reason?  If it is this reason how can I force the dynamically called VI's to run in the development environment by opening LabVIEW programmatically from an executable that is running in the run time engine?
Let me know where clarification is needed.
Message Edited by jmcbee on 04-28-2009 10:00 AM
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
Attachments:
Reuse.PNG ‏14 KB

Answer 1

Hi jmcbee,
      In spite of years of using LV and building a resuable library of code, I've done very little with customizing the standard paletts, however,
Many times when deploying a new distributable I've seen a dialog like what you posted.  In most cases the problem was solved by rebuilding distributable to include the missing VIs.  In one case I added the VI-lib to the target-platform and made-sure VI-lib was in distributable's VI search-path.
There are two ways I know of to build distributables which include the VI-lib code,
1) Include all VI-lib VIs when building the distributable
 - In LV 8x, uncheck "Exclude Files from VI lib" project-property.
 - In LV 7.1 it's possible but I don't remember how! (probably a post on it around here.)
 - This can add an enormous number of un-needed VIs (see this post.) 
2) Re-write the VIs so that they are no-longer identified with VI-lib and get included "naturally".
 - Open each VI diagram, select-all, paste in new/untitled diagram.  In your case naming will be tricky, but it's doable.
 - This is a great advantage in 8x as it allows LLBs to be built with File\Save As\Create Hierarchy.
In addition, here's a tool to call following "Open VI Reference" (if it returns an error.)  This VI open all broken children making it much easier to identify specific missing parts (typically VI-lib.)
Luck/
Cheers!
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
Util.VI.OpenBroken.vi ‏57 KB