Get rid of script nodes! Just kidding, make them better!

[altenbach]

The current implementation of script nodes (formula, mathscript, etc.) is a bit unwieldy. We have to find a delicate balance between node size and content. (too small and we need to constantly scroll the text code. Too big and it is difficult to wire around it and fit it into the rest of the g code.)

My suggestion is that script nodes on the diagram look just like e.g. call library nodes (or possibly express VIs). Double-clicking them would open a separate editor window that floats above the code. Near the top we have a growable area where we can define the connector names, inputs and outputs  (variable name, datatype, etc) and below we have a nice code editor window similar to the current mathscript node, just comfortably big (e.g. like notepad)! At the bottom there could even be extra tools, e.g. like import from text file, save to text file, etc.

Typically the node would be collapsed into an icon but the script window can be left open during editing and debugging.

This is one case where breaking out of the confines of the 2D diagram would be helpful. The current formula nodes just don't really belong directly on a diagram. Nobody want to compose and edit text in an area the size of an old cellphone screen.

This is just a very rough Idea. The details would need to be worked out further....

[AristosQueue (NI)]

What you are asking for is essentially no different from creating a subVI for the script nodes. What advantages would your proposed solution provide over just using a subVI?

[altenbach]

I think it's quite different. A subVI would not provide the same edit-time and debugging experience as I describe. It's something that would not even need a front panel.

[jattas]

altenbach, would you be in favor of getting rid of the current implementation completely? Or would it be better to have two modes of viewing a script node: "inline" (the current behavior) and "collapsed but expandable" (your proposed behavior)?

Aristos, one downside of putting the code in a subVI is that the input and output terminals will no longer automatically adapt if the data types change. You would have to make the change to the script node and the connector pane terminals.

[ErnieH]

Sounds a lot like collapsible code, which we all know is bad. If I understand your idea right, I think it would promote non-modular monster toplevel Vis with all code crammed into one diagram. This should not be encouraged.

[PhillipBrooks]

Instead of collapsing the script into an icon, how about reducing it to look like a Call Library Function Node? It's a familiar concept to LV programmers that call execute non-G logic. 

The script node parameters (inputs and outputs) would grow and shrink as necessary.

[altenbach]

>Instead of collapsing the script into an icon, how about reducing it to look like a Call Library Function Node?

For example as described in my second paragraph? 😄

Yes, an icon is definitely not enough, just because the number of parameters does not have an upper bound. Thinking about this a bit more, maybe a similar format like property or invoke nodes might actually be better (just with a different glyph).

We would have errors near the top and a growable list of connectors below. Each can be input, output, or both, and the variable names shows in clear text. A title area could give the function a name.

And, yes, we should have a choice to show them in-line as we currently do, or collapsed as in this idea suggestion.

(Maybe I'll do some graphical examples of what I have in mind over the weekend....)

[PhillipBrooks]

Sorry, I typed in my comment before the first cup of coffee (6:00 am) and when I returned at lunch I clicked post without proof reading it.

Haven't had my coffee yet today, so I need to step away from the keyboard before anyone gets hurt!

:facepalm:

[Ray.R]

I like the idea of making it look like a Call Library Function Node.  It's easy clean and we're already familiar with it.

Kudos.

[X.]

I unknowingly just posted a kind of duplicate of this idea as pointed by Darin K, with "pretty pictures", for people who have problems visualizing things (:-)...