LabVIEW
Scripting: Enum RingText.SizeToText Error 1029
Im using Scripting in LabVIEW 2023:
RingText.SizeToText can be set to write without a broken arrow. Also Help indicates that Permissions are Read/Write.
But when I run the script I get Error 1029: VI Server property is read-only.
Is this a Bug or am I missing something?
Does your script attempt to change the properties of a control on its own front panel? I expect the error is because the control is only editable during edit-time and your script is trying to do it during run-time.
It is true that the help specifies: "Permissions: Read/Write" on this property, which effectively allows you to put the property node is the "Write" direction at edit time. However, it does not mean it is always writable at runtime. The help also clearly states: "You can write this property only for free labels, control labels and captions"... so not for a ring text.
Since LabVIEW uses the same generic "Text" class for labels, captions, ring texts, ... the compiler cannot know in advance whether this will be an instance of label, caption, ring text, or whatever... so the error will only happen at runtime. This is also coherent with the manual editing, since there is no option "Size To Text" when you right-click an Enum control.
The only option I see would be to precompute and write the ring text width according to the biggest item name.
"Get Text Rect.vi" from the Picture functions can help you compute the apparent size of any text, given the desired font, orientation, etc... :
Regards,
Raphaël.
@raphschru wrote:
It is true that the help specifies: "Permissions: Read/Write" on this property, which effectively allows you to put the property node is the "Write" direction at edit time. However, it does not mean it is always writable at runtime. The help also clearly states: "You can write this property only for free labels, control labels and captions"... so not for a ring text.
Since LabVIEW uses the same generic "Text" class for labels, captions, ring texts, ... the compiler cannot know in advance whether this will be an instance of label, caption, ring text, or whatever... so the error will only happen at runtime. This is also coherent with the manual editing, since there is no option "Size To Text" when you right-click an Enum control.
The only option I see would be to precompute and write the ring text width according to the biggest item name.
"Get Text Rect.vi" from the Picture functions can help you compute the apparent size of any text, given the desired font, orientation, etc... :
Regards,
Raphaël.
To make it more generic, I suggest this:
@code-lux wrote:
I still think LabVIEW behaves not as expected, as I did not choose SizeToText but RingText.SizeToText - so the RingText is explicitly there at edit time!
Strictly speaking, LabVIEW could forbid configuring "RingText.SizeToText?" in write mode, or even hide that item from the properties submenu, but here are some insights on why (in my opinion) this is not the case:
1. Class "Text" is a generic class that represents a basic text component, either on the front panel or on the diagram.
2. Class "Enum" has properties such as "Label", "Caption", "UnitLabel", "RingText" which are all Text objects. These objects are sometimes called "nested objects", since their references are accessible through the properties of the owning object (Enum).
3. You can access the reference to these Text objects by selecting the Enum's properties: Label / Caption / UnitLabel / RingText > "Reference". Then you can use a second property node to access the Text properties. In this way, you are explicitly accessing the property of a nested object. This is sometimes called a "nested property".
4. To ease the access to nested properties, LabVIEW usually (not always) displays the properties of the nested objects in submenus, allowing to access them implicitly with a single property node. But still, this is equivalent to using 2 successive property nodes.
So the reasons to LabVIEW allowing to configure a nested property in write mode even if it can never be written at runtime could be:
- Because the code that displays nested properties in the submenus is generic, it just displays the properties of the nested object's class. NI maybe don't want to complicate that code with exceptions for each possible owner class.
- Even if writing this nested property was disallowed at edit-time, you could still try to write it explicitly with 2 successive property nodes. Here the compiler has no way to know whose the Text ref belongs to. Having the same behavior between the explicit and implicit access can be seen as a choice of consistency.
Regards,
Raphaël.
