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).

[crossrulz]

I think I'm going to side on #2 with the addition that the replace dialog is removed.  I think there has only been once, maybe twice that I chose "no" with that dialog.  I can always disconnect from type def in those rare occasions.  I prefer opening the control editor because that is when I can document the control and change the icon.  Otherwise a lot of type defs will go without any documentation done (which is against our internal coding standards).

[jlokanis]

I also like #2 since this would give me the opportunity to change it to a strict type def if I wanted to.  In many cases, my typedefs are used as both constants and controls throughout my code.  I almost always make them strict unless I can think of a good reason not to.

Also, the 'replace' prompt when closing the editor really seems pointless to me.  In the last 17 years of coding in LabVIEW, I cannot think of a single time I said no to that prompt.  Just get rid of it altogether.

[TCPlomp]

I would go for option 1 (direct save to typedef), because that is the goal of this feature:

Create a typedef, customizing can be done later.

[Minty]

If terminology is the only difficulty with #3. Why not call it "Replace With TypeDef" as you would with changing a string to a dble. Most of us know that a typedef requires a new control to be created.

[crossrulz]

TCPlomp: "Create a typedef, customizing can be done later."

If you don't customize while you are creating it, it is highly unlikely you will remember to go back and do it.  I have been a victim of myself by saying "I can customize it later" and then totally forget to.

[MichaelAivaliotis]

OMG. I didn't even no this idea was on the list. Thanks to AQ for cross-posting to LAVA.

I've wanted this for years. It's one of those ideas which is a no-brainer. Why the @#$% would you allow editing the front panel control and not the one on the diagram. I keep trying to double-click the constant, wanting to edit it and create a typedef. Why can't I do that?

So my suggestion is definitely for #3. Make the operations exactly the same as used for creating a typedef on the front panel. either right-click>customize, or double-click to edit (if that's turned on in the options).

[Christina_R]

As a member of the dev team who is pushing against the "Advanced>>Customize" shortcut menu as the solution, let me explain why I think this menu item is misleading and wrong.

Suppose you have a ring (not an enum) and you want to edit the items. "Customize" sounds like a reasonable way to do that. (Those of you who understand typedef ring constant update problem probably know where I'm going here). If we don't default to making it a typedef, the majority use case suffers because you are always having to select type def from the ring. If we do default the ring to typedef, we are inconsistent with the front panel behavior of the same menu item. Also, the user who intended only to update his ring items may be confused by a file prompt and/or make unintended changes to his VI by replacing his constant with a typedef. Further, the next time he tries to "customize" the ring items, he finds his constant does NOT update to receive the new items, which makes LabVIEW appear to be broken.

[JeffreyH]

I'd prefer option 2 New menu item, "Make type definition", both for BD constants and FP controls (and maybe BD terminals too) and the default action would then be to replace the control or constant without asking the user. To me this seems both very intuitive and the least effort to implement.

I would suggest a configurable parameter though for setting the default control type (typedef or strict).

[jgcode]

Whatever the FP methods are, they should propagate to the BD.

I vote for #3 to keep it consistent and logical for current users.

I.e. Currently I think anything other than Advanced >> Customize in the popup menu would cause confusion.

[Christina_R]

Try not to think just about current, expert users. Try to think how this will look to people who are new to LabVIEW, or who have never used type defs before. 

Advanced>>Customize is primarily for making cosmetic changes to a control. The ability to create a type def from there, although convenient, is not at all apparent to a new user.

A new menu item, on both front panel and block diagram, would make more sense and be easier to discover.