Eliminate Typedef Explosion on Block Diagram

[JackDunaway]

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

Another idea is to link the bundle to the destination:

[chris.b]

Hey all, I tried to take Lavezza's elegant suggestion and make it separate, clean, simple idea: View Cluster Constant as Icon.

[JackDunaway]

I officially support chris.b's idea he linked to above way more than my original solution for "linking a typedef to an Unbundle". The idea has evolved through Lavezza, tst, and chris.b (and plenty others in the rest of the forums) to a much more elegant solution than the one I proposed above. My idea title is still relevant - "ELIMINATE THE TYPEDEF EXPLOSION ON THE BLOCK DIAGRAM" - but a better implementation of a solution is outlined in chris.b's idea.

[AristosQueue (NI)]

After a lot of thinking about this, I am ready to put my support behind a specific implementation of this idea, very similar to what is described by jdunham above, except rather than handle the non-default version, I'd leave it out (explanation of why is below).

1) Drop typedef on diagram.

2) Pop up, select "Show as icon". If data in typedef constant has been  modified in any way shape or form, this option is grayed out (or you get a dialog explaining why "Show as icon" cannot be applied.

2a) A typedef .ctl file can have non-default values set into the controls. When you drop the constant, the constant appears with those non-default default values. Those constants do not update when you change the default value back on the .ctl. Thus I would consider these to be controls that cannot have "Show as Icon" applied. [Note that making these constants update when the typedef changes would be both technically difficult and a significant change in the behavior of .ctls, so I don't think that's an option.]

3) When in icon mode, Copy Data works but not Paste Data (again, you cannot have any value other than the default default value).

For LabVIEW classes, we allowed "Make Current Value Default" even though you cannot see the value. We've taken some flack for that, and most people I've heard from now think we should've disallowed that. I want to avoid that with the clusters/typedefs. Even though you could see the value of these iconified clusters (context help, turning off "show as icon", etc), you couldn't see it in a static snapshot of the diagram, which seems to be highly desirable based on the feedback I've gotten about what to do with the LV class constants. Thus having everything be the default-default value means you don't have to see the value to know the value.

[JackDunaway]

AQ, thanks for the inside support. I think it would be appropriate for the moderator to basically wipe out my original post, pictures and all, because it describes a "solution" that's not applicable as far as anyone is concerned. Really, the only information is the title: "Eliminate Typedef Explosion on Block Diagram." The only text in the body should be a link to chris.b's idea, and this idea should be marked as a duplicate. Does that sound legit?

[JackDunaway]

View Cluster Constant as Icon has been marked In Beta for a while, and Kudos for that Idea have been disabled. I'm going to notify the moderator requesting Kudos be disabled for this post (as it is now moot) since I think most of the supporters (including myself) abandoned my original "Link to..." implementation in favor of the cluster constant icons.

I would also like the Idea Status of this Idea be changed from "New" to something along the lines of "Evolved into something better", or "Superseded", or "Supplanted", or "Displaced".... please check out "Archiving Ideas - Feedback Requested" for relevant discussion.

[JackDunaway]

Three and a half years later, looking back on this idea... it's not so good. It's actually quite bad.

I have proposed two bad IDE/language solutions: a hidden configuration, and also upstream type propagation.

Plus, it's trying to solve a problem that's only caused by bad API design in the first place -- if the data structure members had been fanned out onto the API method interfaces, the calling diagrams would not have been exposed to these problems in the first place!

And finally, this problem hasn't even bitten me in a couple years since LVOOP. So it's not even a problem one faces if supplanted by good programming practice.

I respectfully suggest this idea be declined and closed. 😕