ShaunR

That's probably a good idea and we can get an moderator to move the previous posts over.

Oh wow. I thought it was just buggy and overwriting my other images. I always used the file import because of that.

As this has popped up again and someone may find it useful. Here are some comparative benchmarks between LabVIEW and OpenSSL hashes (sorted fastest to slowest).

The System Button has the mouse over images. You can't "import parts", only the images for the states. That includes if you simply want to change the mouseover colour (copy the image, paste it into an image editor, change the colour, then import it back again). The mouseover also only works while the VI is running.

You have to program all that yourself.

OK. Decision made - reinvent the wheel The final nail in the coffin of using something like Paho MQTT was DLL distribution and integration with current features.

Me neither. What exactly are "the LabVIEW suite of offerings"? (Please don't tell me BridgeVIEW or whatever they are calling it now )

Well. They are not really equivalent. System Link is, first and foremost, a configuration and asset management tool. Buggy? Maybe (I haven't looked recently) but that could be addressed. WATS is specifically a data analytics tool. WATS has more in common with Diadem than System Link.

We shall see. The "Fat Lady" hasn't sung yet and Emerson shareholders seem more than a little unhappy about the takeover. I'm still bullish on this failing despite Dr T's intervention. The more I look at it, the more this seems like taking out the competition as opposed to diversifying and entering new markets. I think System Link was probably the trigger for this as it could, in the future, take Emersons offerings head-on and provide a far more superior top-to-bottom solution given NI's driver, LabVIEW and Test Stand support.

Actually you can sort of do this already but it's not native. Websockets made this possible. All it requires is to be able to map a web page to a front panel and come up with a protocol. It is surprisingly easy as long as you don't use panes. It would seem to be a nice feature to just lay down LV controls and for them to be replicated remotely, but then it'd just look like a LV front panel in a browser - you might as well send an image. You need to be able to customise the HTML and the LabVIEW IDE would make an awful HTML editor. It's far better to make the HTML (or get a web-dev to do it) and tell LabVIEW what controls were pressed - effectively separating LabVIEW from the FP the user interacts with. But I was thinking more of VI server being the interface for LabVIEW as a back-end, function server so that in addition to the above, it could also act as binding for other languages (RPC). They did something similar with their webserver where you could call functions but it was a hideous solution requiring deployment of the NI Webserver and Silverlight etc. You could map a web page address to a VI to call. VI server has much finer granularity than just user VI's and, IMO, should have been the starting point.

Their logical conclusion would be that it's not a big market and we can't support it. You can say goodbye to LabVIEW, IMO. This is a fantasy. Python is well known for being poor at multithreading, if you can call it multithreading. I understand that you are just trying to find a new place for LabVIEW but getting Python to support a data-flow paradigm is probably a bit too much. We have a number of programming languages and paradigms at our disposal so why try to shoe-horn everything into Python? Use the right tool for the task. I don't use LabVIEW when writing webserver code. IMO, LabVIEW's biggest weakness is the UI. Python isn't a good improvement on that and vice-versa. LabVIEW would also be a very expensive and cumbersome development tool just for planning and maintining python applications. Perhaps a more realistic solution would be to improve the LabVIEW VI server so that it could interface with other languages directly using TCP - make it more like an RPC interface. That may scratch your Python fetish itch.

I think the C compiler was (or was based on) on the Watcom compiler. Well. Callbacks are a poor-man's event. The C/C++ industry has always had problems with fitting event driven programming into their straight-jacket. They are being forced to nowadays with Service Oriented Programming and all they have is callbacks as an answer-leaving the programmer to figure out threading and asynchronous operation. It's why I prefer Object Pascal (Delphi, Lazarus et.al.) over C/C++

I always felt they could have had a tighter integration between LabVIEW and CVI. It could have solved our lack of being able to use C callbacks for a start. A CVI node like the Formula node could have been quite useful too.

Maybe. Although he's getting on a bit and has an interest in Alzheimer's. Could also be looking at passing an inheritance where a cash drop like this would be great. Difficult to understand he'd be happy about his life's work being swallowed by another corporation just for a few decimal points of his billions in cash. Interesting he talks about "stakeholders" instead of shareholders but it does not bode well for NI. The plot thickens!

I like your solution. I've always used moveblock with strlen which, although it seems faster, is far less intuitive. On a different note. Try not to use those utility functions at all. They all run in the Root loop! I may use them for prototyping but always replace them in production code.