Changing VI description at runtime is not visible in palette

[fasti]

Hello everybody,

i am new here so I hope I can provide every info needed for my (seemingly) complex question.

What I want to do:

I want to translate the description of VI`s programatically while my programming is starting, so that the description shown in the context help window is translated properly.

The language is configured in a text file and is read while the program is starting.

Therefore, when starting my software i execute the VI I want to translate and hand over a bool to the VIs connector pane, indicating that I am currently in a boot state.

The VI then gets the translated description with a function implemented by me and sets its own description accordingly.

How it does that is not important and works fine.

My problem now is the following:

The VI I want to translate is placed in a custom palette and my program is now started completely.

So I create a new VI and want to use my translated VI in there.

When I drag the VI from the palette into the block diagram of my new VI, the description in the context help window is translated correctly.

But when I hover over the VI in the palette, the description in the context help is not translated and shows the default description I have set in the VI`s properties window beforehand.

So my question is: Is there any way I can set the description of a VI programatically, so that this adjustment is also shown in the context help when I just hover over the VI in the palette?

My assumption on why this is happening:

When loading the VI`s description while hovering over it in the palette, the VI is not loaded in the user context yet, but is just in some palette context. Therefore the VI might not have been executed yet. But I am just guessing wildly here.

Some context information:

- LabVIEW 2023Q3 64-Bit

- Windows 11

The VI i want to translate is located in an lvlibp.

When I start the program, I execute a .exe file, that just triggers code in a llb. This code then loads everything needed and is responsible for the boot process of my program (starting the vis once for translation, creating the palettes, etc.).

Does anyone have an idea on how to solve this issue?

[Yamaeda]

Works for me. (i made a lvlibp to test and managed to read and write the property)

I made an Exe of the VI and nothing happens, so i assume its' not possible/allowed. Enabling Debugging didn't help either.

[Kyle97330]

I haven't tried using it in code to see if it helps or not, but have you tried the Application class method to refresh the palettes?

https://labviewwiki.org/wiki/Application_class/Palettes.Refresh_method

[fasti]

Yes, i am doing that during startup after the palettes have been created (the vi in the lvlibp is in a sub palette there).

The sub palette is created and stored in the lvlibp in an .mnu file.That is done manually before the lvlibp is built.

This .mnu file is then used to add the sub palette to the main palettes items during startup. After that, the palettes are refreshed.

[rolfk · Accepted solution]

A lvlibp is not modifiable by you. Once built it is a read only BLOB.

The Application-builder knows how to create it but has no methods to modify it either.

[Yamaeda]

---

@rolfk wrote:

A lvlibp is not modifiable by you. Once built it is a read only BLOB.

The Application-builder knows how to create it but has no methods to modify it either.

---

I actually thought you could change it in memory, but alas.

[rolfk]

---

@Yamaeda wrote:

---

@rolfk wrote:

A lvlibp is not modifiable by you. Once built it is a read only BLOB.

The Application-builder knows how to create it but has no methods to modify it either.

---

I actually thought you could change it in memory, but alas.

---

Several problems with that. The LVLIBP uses internally a special file format that makes it easier to load it right into executable memory and execute it from there (Fast File format that can be also enabled for EXEs). Writable Execute memory is however a very very bad security "feature"!!

[Yamaeda]

---

@rolfk wrote:

---

---

Several problems with that. The LVLIBP uses internally a special file format that makes it easier to load it right into executable memory and execute it from there (Fast File format that can be also enabled for EXEs). Writable Execute memory is however a very very bad security "feature"!!

---

Very true! It'd be prone to code injection and buffer overflow and whatnot.