User | Kudos |
---|---|
5 | |
2 | |
2 | |
2 | |
1 |
Case study 1 (Clustosaurus): The "View Cluster as Icon" is a great addition to tidy up diagrams. So we build our diagrams nice and tight and when comes the inevitable moment when we want to edit that constant, the diagram explodes (unless we turned off the autogrow feature, which not everybody may want).
Case study 2 (String): Likewise, when we want to connect a verbose message to a string input, we might scale the constant down so that it occupies a small footprint. If we want to read or edit it, we need to expand it, and that causes a similar problem as before.
Case study 3 (Formula/Mathscript Node): Suppose we have a formula or mathscript node somewhere and we have squeezed them down so that they don't occupy 1/4 of our screen, but we now want to have a way to edit them full screen. We can use their scrollbars, but it feels like LV on an iPhone...
I guess I could go on and on. The bottom line is that all these situations call for a simple way to temporarily edit an object in a separate window, before closing it and having the object get back to its initial size and location on the original diagram. There are potential abuses with this approach (for instance cramping a huge messy diagram in a case structure), but the simple solution is to prevent this from being usable with the potential trouble makers (structures, to name them).
My 2 cts.
PS: of course we could create a custom control from a cluster constant (although that is not yet possible), edit it and close it and chose "replace constant with custom control". Likewise for a string constant. But that would not work with nodes, obviously. So I would accept the ability to create a custom control from a constant as a partial solution.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.