LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Anonymous Method Structure

The ability to define anonymous methods to be called multiple times within a block diagram.Capture.PNG

 

 

18 Comments
Proven Zealot

Another favorite brainstorm topic of mine.

I have several drawings around that look vaguely like that.

I don't know why you have those "10"s wired or the orange wire coming out of the structure... pretty much defeats the purpose... but otherwise, yes, I like the idea. Wish I had the spare bandwidth to chase it more.

Proven Zealot

My diagrams tend to look more like this:

Untitled.png

I have many variations on this theme.

Proven Zealot

For example -- let's make that "define connector pane" input optional. It's sometimes useful, but not always. So...

 

When you drop a Anonymous VI structure on the diagram, let's create one on the front panel also. Any control you add inside the rectangle on the FP puts its FPTerminal inside the structure on the block diagram (and cannot move out). The structure on the panel has a small rect where you can connect terminals to the local conpane. Now you don't need a separate input to define the type AND we have a definition for the anonymous VI's front panel, which will help with debugging.

 

What do we do for a panel if you do wire that "define connector pane" input? Well, LV can autogenerate one -- default control for each type.

Proven Zealot

Note that if you put the Anonymous VI structure inside a loop, you get a different refnum every time you call it -- each one closed over a potentially different value of Numeric. It's essentially a reentrant clone with an injected value -- there's a constant in its compiled code that is varied for each clone.

 

You want some really fun brainstorms? Draw a channel wire crossing that Anonymous VI structure boundary and ask yourself if that's meaningful. Hint: it isn't meaningful as channels are defined today, but the places it'll lead you in terms of async communication models and models we might use for them are intriguing.

Active Participant

So basically, create a sub-VI without creating a separate sub-VI.  Took me a while to work out that was what was meant!

 

In response to AQ, I do like the idea of defining controls, but I don't think it should be on the main VI FP.  As an alternate suggestion, controls could be embedded into the AnonVI border in the BD, and the connector pane could be in the top-right corner of the structure, with the same functionality as a normal ConPane but applying to the embedded controls/indicators.  If a FP is needed for debugging, then that can be defined separately.

AnonVI.png

If that's not possible, then I'd prefer a pop-up FP with connector pane, and pretty much no other menus or icons, and not to use the main VI FP.

 

This idea has a lot of overlap with an idea I suggested way back, which I thought was pretty good Smiley Happy

Proven Zealot

> So basically, create a sub-VI without creating a separate sub-VI.

 

That's the minor aspect. Sure, it's nice to create a VI no one else can call and eliminate a file from disk. But the big gain is the closing over run-time values and the performance gain thereof.

Proven Zealot

> This idea has a lot of overlap with an idea I suggested way back, which

> I thought was pretty good Smiley Happy

 

Please see my new comment on that idea. (Avoiding further comment here to avoid hijacking this thread.)

Member

Nice try JavaScript... Smiley Wink

 

I do  see the benefit, and I use it a lot in node is, just in the context of a subvi I don't see how it will improve readability. Perhaps in a top VI with a case structure executing same code, but what stops you making a subvi.

Proven Zealot
oskretc the closing over caller values cannot be done with a subVI. At best you can put a control on the front panel, NOT connect that control to the connector pane, and then on the caller diagram, create a new reentrant clone and then set the value of that control on the panel. Terrible performance, complex code, and very error prone.
 
 
 
(Note you may have missed -- the call to the anonymous function is typically not on the same block diagram as the declaration of the anonymous function. It is typically passed into a subroutine and called several layers deep within a framework. Different callers of the framework would instantiate entirely different VIs and use different closure values for every call to the framework.)
Proven Zealot

PS: Not sure what the reference to JavaScript is about. This can all be done strongly typed, unlike JS.