Showing results for 
Search instead for 
Did you mean: 

Frame Names for Disable Structure

Go to solution

I'm currently trying to script the creation of a Disable Structure with several "ready-to-use" cases (possibly more than 2, so the developer can quickly choose the case that best suits his needs).


Since the default frame names are not very helpful for choosing (e.g. for 3 cases: "Enabled", "Disabled", "Disabled"), I manually changed them to e.g. "Default Model", "Single Action", "Loop", ...). However, I couldn't find any property in class DisableStructure to do it with VI Scripting. (I use LV 2016, apparently the frame names are not manually modifiable anymore with LV 2018, which is too bad...) 


It is already present for other MultiFrameStructures:

 - for CaseStructure, we have the readable/writable property "FrameNames";

 - for EventStructure we have the readable property "EventSelectors" to get the selector texts and the method "SetHandledEvents" to set the events;

 - Actually for DisableStructure, there IS a property called "Conditions", but that only works for DisableStructures that have the "Conditional Disable Style", otherwise it throws an error.


How can I get/set the frame names for a regular DisableStructure ? Any private/deprecated property maybe ?


By the way, as a future improvement idea, it would be better to have a single readable/writable property "FrameNames" for class DisableStructure (working for both regular and conditional style, replacing the "Conditions" property). It could even work with Type Specialization Style! Indeed, the frame names "Accepted" / "Ignored" are not helpful neither. It would be great to be able to name the cases e.g. "Array", Scalar", Cluster", ... indicating each type the cases manage, directly visible in the selector. Just as the 2 other styles, an asterix [*] in the selector could be added to show the active case.

0 Kudos
Message 1 of 10

How about you just enable visibility of Subdiagram Labels and then use those?

0 Kudos
Message 2 of 10

I couldn't find anything.  I would suggest using subdiagram labels as an alternative.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 10

I imagine the issue with subdiagram labels is that you can't see the label until you make the selection and the selection isn't clear since all but one will just show "Disabled". If there aren't too many cases, you might want to just put the frame names in a label above the structure as a way to "label" the frames.

Matt J | National Instruments | CLA

0 Kudos
Message 4 of 10

Well, after playing around for a couple of hours, I finally came up with a rather satisfying solution.


I knew the selector was actually a text object, which doesn't appear to be accessible by any property, so "Traverse for" was not helpful. I could only get its reference using a right-click plugin, which is not very practical...


So I used the amazing "UID to GObject" to try every UID starting from the Structure's UID, since it is a sub-object, it must have a bigger UID. Being rather generic, this technique could be used for solving similar problems...


PS : this VI does not work for Conditional Disable Structure, so use the property "Conditions" for this case. I've not tested with LV 2018, but it "might" also work for Type Specialization Structure.


So here is the result:

0 Kudos
Message 5 of 10
Accepted by topic author raphschru

Corrected an obvious loop indexing bug:

0 Kudos
Message 6 of 10

Cool, but fragile.  It assumes the first text object encountered is the frame name.  Currently there is only one text sub object, but that's not guaranteed to be the case in the future.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 10

Yes, can't think of anything better since there is no "Selector" property.


Moreover, the request of the intermediate UIDs seem to allocate something, since it takes longer the first time on a given DisableStructure instance... I wonder how that "UID to GObject" internally works (but password...).


NI gives us "Frame Selector Rect", while all we want is simply the Selector's reference.

0 Kudos
Message 8 of 10

I made this from your code.


Note: "UID to GObject" is nothing more than a wrapper for a DLL call:

int32_t UidToObjRef(const int32_t *VIReference, const int32_t UID, int32_t *LVObjReference);


"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 9 of 10

Nice, but you're also assuming that owned subobjects have consecutive UIDs, which is probably right, but who knows...

The UID attribution logic for objects and subobjects in a diagram is a bit obscur for me...

0 Kudos
Message 10 of 10