Create type def from block diagram constant

[crelf]

As mentioned here, "I lost count of the times where I have a cluster or enum constant that I want to make into a type def and have to first change it into a control, switch to the FP, and then select customize" - it'd be great to be able to right-click on a constand (like a cluster) on the block diagram and select Advanced -> Make Type Def (of course, you'd need to save the type def somewhere).

[crelf]

Gimmie either #1 or #2 without the dialog.  That said, if you give me #2 without the dialog then I'd think about removing the dialog for FP nodes too...

[Daklu]

Not #1.  Most of the time that is what I'll do, but occasionally I open up an untitled project and code up a couple vi's to prototype something I'm thinking about.  I don't want to save them, I just want them in memory until I'm done with them.  Having to save it before I could use it would annoy me.

Not #3.  Right-clicking is called "context click" for a reason; it brings up a menu of items that are appropriate for the item being clicked on.  In this case it is a constant--an entity that only exists on the block diagram.  I don't see "that's how we do it on front panel controls" as a compelling reason to put the menu item in the same place.  I suspect experienced LV developers will quickly adapt to the ability's new name and location for constants.  (Maybe I'll post an idea to change the fp "Customize..." menu location to match that of the constant "Make Typedef..." menu location.)

#2 is imo the most logical choice.  Drop the dialog box though, or at least give me the option to disable it... there's already too many of them in LV asking me if I'm "really, really, sure I want to do that."

[Dan_DeFriese]

I vote for #3.

Don't over think it. Don't semanticulate it. Don't screw with the editor. Don't invent some "New" thing called a "custom constant" or something silly like that. Just allow me to skip the part where I'm currently forced to make the constant an fp control first.

But we already have an RFC plugin which usually works as long as LV doesn't crash. So take back my kudo as work on stability! (Just kidding. #3 just seems like the most natural option.)  

[GregSands]

I vote for #1 - that's how I would tend to use it.  I think the menu item should be "Replace with new Typedef Control", which does exactly what the menu states (no editor).  It should automatically add to the same project and/or lvlib of the original VI.  I'm ambivalent whether this needs to be saved immediately or not.  To make it clearer that there is a now-editable control (i.e. .ctl file), perhaps it should automatically create a simple icon (e.g. TYPEDEF CLUSTER 3) and change its view to be As Icon.

[Christina_R]

I like the idea of changing the constant to View As Icon. This could help disabuse people of the mistaken notion that their typedef cluster constants will retain their element values and layout when the typedef updates. If we could extend View as Icon to work for all typedefs, it could also help people avoid the common mistake of expecting constants from strict typedef rings to get updated with new item names like controls do.

[AristosQueue (NI)]

> I like the idea of changing the constant to View As Icon. This could help disabuse

> people of the mistaken notion that their typedef cluster constants will retain their

> element values and layout when the typedef updates. If we could extend View as

> Icon to work for all typedefs, it could also help people avoid the common mistake

> of expecting constants from strict typedef rings to get updated with new item

> names like controls do.

I make a typedef of my enum. ZAP! And now I no longer see what state my state machine transistions into...

That doesn't sound like something we should be encouraging. I think the "view as icon" form is fine ONLY as long as the value of that constant is restricted to being the default value for the data type. At least then I know what the value is when it is in icon form when I read someone's diagram. I don't like the people that have custom values for their constants and then hide them in compressed form. For the record, I didn't really want "make current value default" to work on class controls/icons since you can't see that value, but many people felt we needed the feature. I am surprised more people don't find that it makes diagrams really hard to debug.

Not to mention that a 32x32 icon is way bigger than an int32 and taller than an enum constant. The folks who want compact diagrams aren't going to like that.

With LV classes, we do make the small change of turning the cube's background black when the value is not the default. Perhaps that would work here. On the other hand, if all you're looking for is a visual change to the constant that tells the user "yes, something actually happened", then a small glyph should suffice. Can we instead try to add a glyph to the border of all constants that indicates that the constant is linked to a typedef? That would be nice to have anyway so I know which ones I forgot to make into typedefs.

[tst]

> ...add a glyph to the border of all constants that indicates that the constant is linked to a typedef? That would be nice to have...

You're not the only one who thinks so - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-constant-is-linked-to-TypeDef...

[AristosQueue (NI)]

Related idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/one-click-save-control-as-typdef/idi-p/1330240#M9263

[G-Money]

Available in NI LabVIEW 2011 Beta