How can I use the write palette.vi in an application when it is not supported by run time engine

[crossrulz]

I still don't see why you couldn't do this with VIPM.  Each time you deliver an update, you just make a new package.  The user then just updates to the new package.

[nperhach]

Knutson, maybe I was not creating the mnu file properly when I tried it that way. When I transfer the mnu file and the VIs the connection is lost between the two because the files aren't saved in the same location. Also, because the files are coming from perforce and everyone has a difference workspace I cannot see how I can keep the location the same so the mnu can refer to the VIs when the directories will not be the same.

Zealot, that is pretty much what I have so far where I package the VIs and the application together. And the user can save the folders on their computer and run the application to install the VIs as a palette. The VIPM would be a great way to package them but I need to have the packaging automated and if it does not have a command line interface I am not sure I will be able to automate it. 

[crossrulz]

---

nperhach wrote:

Zealot, that is pretty much what I have so far where I package the VIs and the application together. And the user can save the folders on their computer and run the application to install the VIs as a palette. The VIPM would be a great way to package them but I need to have the packaging automated and if it does not have a command line interface I am not sure I will be able to automate it. 

---

Zealot is my status, not my name.

JKI does have an API for playing around with VIPM through LabVIEW.  I think it might need the professional version to be used.  That might provide the automation you need.

[nperhach]

Oops my mistake, thanks I will look into it.

[Dennis_Knutson]

No, you would have to enforce the same directory structure. That is what I did with multiple developers using both TestStand and LabVIEW. Everything on the default locations just like an instrument driver from NI.

[JÞB]

---

@Dennis_Knutson wrote:
No, you would have to enforce the same directory structure. That is what I did with multiple developers using both TestStand and LabVIEW. Everything on the default locations just like an instrument driver from NI.

---

And, as I explained, when working in a working directory <ThisCustomersStuff>  your developer's menu has nothing to do with delivered product during development.  Yes some features could be added to the tools>>advanced..... edit pallet set...options (ignore directory if in llb,  lvllib or lvclass or by scope would be nice!)  but we deliver solutions----not problems! the mnu can be part of the source code distribution if you are delivering source code!  If you are developing source code for internal development ---I suggested something useful

You really need to differentiate "Releases" vs "Commits" What aids your developers? what aids your developer's clients (gets the developers paychecks processed)?  Promulgating unreleased vis as palatte menu features..........I do not get that!  unless, the developers are really working in the same <directory>  At that point, the mnu file in the source distrobution should be in  a build!!!!...it does not help your developers of the source code unless they have access to a development machine and the perforce locks are not ignored on principal!

Are you not using projects and libraries?