LabVIEW
Good things from NXG that I would like to see brought over to LabVIEW classic
improved TCP/IP network palette
- Support for IPv6 adresses
- property nodes on the network refnum that allow access to some more commonly used network socket options: TCPNoDelay, Buffer size, local and remote address and port number associated to the underlaying socket. Also add more TLS options in this way to the network refnum.
- Some fringe options like allowing to specify the local address to bind a connection too when calling the Connect function. (Listener allows that now)
It would require some breaking changes like strings everywhere for IP addresses, removal of the int32 address data type althogether (the nodes could retain that option for backwards compatibility but not allow it for new code). Most of that can be easily mutated for old existing code with the LabVIEW conversion tools that already exist, but are also not documented for external use outside of NI.
An official refnum API to use in external code
for our own libraries. There is currently no official way to create refnum based APIs. (I figured out some of it but since it is not officially documented it feels a bit like playing russian roulette to use that for anything to be released). Would be cool if it allows extension of the refnum through property nodes like the objmgr interface currently used internally.
With such a documented API, there would have been a working TCP library supporting all the above mentioned features since LabVIEW 7.1!
- Properties window. I liked the docked window readily available there. Since NXG was MDI based, a docked window made sense. In LabVIEW, it could be a floating window, similar to the Context Help and the Tools Palette.
- LabVIEW definitely needs a reskinning to vector graphics. I will say that I HATED the color scheme in NXG. But vector graphics are pretty much a requirement in modern software. And directly related to this is the zoom feature. 100% agree with Weibe that it should only be a zoom in. I don't want a zoom out.
- I really liked the concepts of the System Designer. Being able to create a project showing the connections to instruments, cRIOs, PXI chassis, etc. is quite useful. This is not a "must have" to me. I know it is being ported to other tools, so that will likely work for now.
- I know a lot of people want Unicode. Personally, I have not ran into it, so it is fairly low on my priority list.
- I didn't get to play with them, but I liked the promises of Components. I can't say anything more on that.
- The layout grid (everything is on a 5 pixel grid, ensuring tiny wire bends do not happen.
Some of the Idea Exchange posts related to my TCP/IP improvement idea above (can't edit my post after more than 30 minutes from its initial posting).
Network refnum property node:
Allow more fine grained control of network socket functionality by seperating Connect into a Create() and Open() function (with option to define local address to bind the socket to):
@rolfk wrote:
Some of the Idea Exchange posts related to my TCP/IP improvement idea above (can't edit my post after more than 30 minutes from its initial posting).
Network refnum property node:
Allow more fine grained control of network socket functionality by seperating Connect into a Create() and Open() function (with option to define local address to bind the socket to):
Are these things are implemented in NXG?
Search LabVIEW like a graph! 
I'm still surprised dynamic controls isn't mentioned more often. With dynamic controls I mean placement of new controls while running.
That would make a world of difference to the way I have to program right now. Especially programming UI configuration for functionality in a class hierarchy (e.g. configurable modules) is plain hell at the moment. Pretty sure this would give a hole new dimension to QControls as well.
My only guess is people gave up after 20 years...
But it is available in NXG. Although pretty useless as there wasn't much you could do with the references... At least not last time I tried.
Haven't seen it mentioned, but having duplicate (or even multiple) terminals of the same FP elements was an interesting alternative to locals.
