From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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).
I have done this atleast 2 times today alone. I use labview everyday for over a decade so I have done this thousands of times in my life, this feature would save me a many hours by the end of my career.
I agree this would get lots of use. Therefore, I suggest not putting it under the Advanced menu when you right-click, just put a selection a the top level of the right-click menu. When you select Make Type Def it would then just give you a save as dialog.
We were brainstorming possible approaches to the feature and came up with the following ideas.
Provide a new menu item, "Make type definition" that does not open the control editor, but presents a file prompt to decide the file name for the typedef. This menu item is applicable to both block diagram constants and front panel controls. We would retain the "Customize" menu item as it is.
New menu item, "Make type definition" that opens the control editor but defaults the ring to "type definition." One more issue regarding this is, the dialog box asking if you want to replace the constant with the typedef. Is the dialog necessary as we are creating the typedef for the sole purpose of using it?
Enabling the "Customize" menu item on the block diagram constant popup, which works exactly like it does on front panel controls.
Ideally, I would probably prefer if there was an option which immediately replaced the constant with a typedef, without even requiring the user to save it. This has an issue in that there's no indication that anything happened and that you will be asked to saved the typedef when it leaves memory.
In practice, the most reasonable solution is probably #3, mainly because it has identical behavior to what users are already used to.
> In practice, the most reasonable solution is probably #3, mainly because it has identical behavior to what users are already used to.
#3 feels really weird when we talked it through. The control editor that appears today starts off set to "custom control", which is not what anyone wants from the diagram. Most of the "customize" aspects aren't even reflected on the diagram, so calling it "customize" is odd, at best, or misleading, at worst.
AQ - I agree it seems out of context to use the term "Customize". It seems the root problem is that type defs are created and controls are customized using the Control Editor. If there were two clear tools - Typedef Editor and Custom Control Editor - the definition would be clear: a new menu item called "Create New Typedef" would launch the Typedef Editor, and the context of visual customization would not even present itself.
This is another topic altogether, but if the granularity of the Control Editor was redefined (the root problem resolved), there would be little question how to present the UI for this Idea. (This is probably an unlikely venture with LabVIEW as we know it, given the inertia of the Control Editor.)
> (This is probably an unlikely venture with LabVIEW as we know it, given the inertia of the Control Editor.)
More than that, if refactoring the control editor is a prereq for this idea, I guarantee it doesn't get attention in LV 2011. Focus on keeping the feature small and low risk if you want it in 2011... which brings us back to the three options laid out by Chethan, or some variant thereof.