Dear NI

[X___]

And meanwhile, Colonel Kodosky is mulling the future of LabVIEW in his fortified Texas compound...

 

 

[ShaunR]

3 hours ago, X___ said:

And meanwhile, Colonel Kodosky is mulling the future of LabVIEW in his fortified Texas compound...

 

 

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication of boiler-plate code we have to do when the real goal is not to have to replicate at all.

A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal?) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too, since what we have to do is figure out who sent the message and act accordingly-the event structure already knows who sent the event.

Edited January 28, 2022 by ShaunR

[X___]

40 minutes ago, ShaunR said:

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication we have to do.

A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too.

What are you referring to? "futuristic" features or "super-futuristic" features?

Personally, Colonel Kodosky's vision scares the bejesus out of me. I imagine an application whose diagram contains a single icon of itself, which when you click into it, sucks you into the matrix and shreds you to bits... I mean wires.

[Phillip Brooks]

On 1/28/2022 at 6:48 PM, X___ said:

Personally, Colonel Kodosky's vision scares the bejesus out of me. I imagine an application whose diagram contains a single icon of itself, which when you click into it, sucks you into the matrix and shreds you to bits... I mean wires.

 

Just watched the video 

 

 

Edited February 2, 2022 by Phillip Brooks

[ShaunR]

45 minutes ago, Phillip Brooks said:

 

Just watched the video 

 

 

Yes. It's not a new idea, BTW. This is the route ladder logic went for state machines in PLC's.

Ignoring the boiler plate scripting for a moment. What is really missing is an intuitive way to view a program's structure. I said a long time ago that we need something similar to (the now defunct) Firefox 3D View. This could be a mode of the VI Hierarchy diagram allowing us to inspect the way subVI's are interconnected and allow us to zoom in and isolate areas of interest.

Event and queue [message] tunnels or the "Channels" could easily be shown which are invisible with the tools we use today.

 

[X___]

I can see why it is defunct...

Personally, I would settle with fixing all the decade long bugs and having support be more useful than it has been my experience. Kind of gnaws at one's desire to engineer ambitiously when one has to hack around bugs or longstanding issues.