Decoration labels

[Luminociter]

Dear all, this might be a mistake form my side, by I am developing an application that programmatically changes the UI with respect to the user's input. I am using some decorations (in retrospect this might have been a bad choice) and when the user selects an item from the drop dawn menu the decorations have to move to a different position in the front pane.

I implemented this using UIDs and then position property nodes to move the decorations around in each case. Although when in development mode when i test the application everything works great, when I built the exe, whatever is programmatically adjusted using UIDs does not seem to propagate to the program. Is there an option I am missing to compile vi scripting?

I am using LV2016 32bit and I am attaching a small code sample of what i want to do. This works in interpreted mode but not in compiled. Any ideas?

[JÞB]

Scripting is not available in the run time Engine.   Period!

Decorations have no label property.

I would use a strict type def indicator customized to look like a decoration.

[Bob_Schor]

Label decorations can easily be placed by String (or Numeric) Indicators, which (as Jeff noted) have the advantage that you can alter all of their properties at Run Time, including their Visibility, Size, Position, Color(s), format (and size) of their Contents, even (somewhat harder) fitting the Decoration to the size of the content.  This should work equally well in Development and Execution mode.  You also don't need to go "looking" for it -- it has a Label.

Bob Schor

[altenbach]

From simply looking at your code, I feel that you are barking up the wrong tree and whatever you are trying to do would not need any of that.

Your example is very poorly written (greedy loop, unnecessary coercion, highly duplicate code, diagram constants for UID even though you determine the value, etc. overuse of local variables (none are needed!))

Can you take a step back and explain from a UI point of view what the user should see how he interacts with the front panel, and how the UI should react in response to his actions. I am sure there a significantly better approaches to all that.

[altenbach]

---

@altenbach wrote:

Your example is very poorly written (greedy loop, unnecessary coercion, highly duplicate code, diagram constants for UID even though you determine the value, etc. overuse of local variables (none are needed!))

---

For comparison, here's a leaner (but literal!) rewrite of your code. (The entire thing to the left of the loop could be eliminated, of course!). Since your two boolean indicators are always hidden, it seems they only serve as scaffold for local variables and can now be deleted. (It was not clear from the beginning why you need two indicators, because the value of one is sufficient to determine the value of the other here during run here, right?)