ShaunR

As do browsers. But perhaps it helps to think of it another way. Once you have completely separated the UI from the working code with a cross platform, standardised communications scheme (like websockets, WebRTP, TCPIP or UDP) you are not just limited to browsers or even LabVIEW - you can create interfaces in any language rather than patching LabVIEW. However. If you intend to support cross platform for the UI then doing as you suggest means you will end up with [a minimum of] 3 different and distinct code bases along with all their test harnesses and build tools (probably in different languages). You are also a bit stuck if you want to see the pseudo interfaces of embedded applications that LabVIEW provides natively. It is a maintenance nightmare that browsers solve quite nicely and, if you are as incompetant with an ebrush as I am or almost at the deadline, you can outsource the UI to web developers while you do the interesting stuff. There's always a few web-devs hanging around IT departments and they can argue about layouts, corporate colour schemes and logos. Maybe we should move all this to another thread if we are not finished?

LabVIEW is cross platform (Windows, Mac and Linux).

No problem for me. The Websockets support HTTPS (wss://) when this is installed and it has proxy support (HTTP with NTLMv2 auth and Socks 5 with basic) I don't know what "Evergreen UI code" means but sandboxed has never been a problem. Besides. As I said earlier. I've been playing with Rainmeter which doesn't use a browser and is more like desktop gadgets. I've never used the NI web server for webservery things (there is no public security analysis). I've always used Apache or Nginx but never for streaming or real-time; its too slow. Nice to see the community taking security seriously at last

Ignoring the obvious Gif (and apng)........ Dynamically create controls. Tables with child controls in cells. Proportional control resizing. Tab controls that work properly. Window and graph animations. Skins. Drag and drop....shall I go on?.

There's no magic here. Browser + websockets + LabVIEW. It definitely doesn't make me a web developer, that's why I want to use Rainmeter because I suck at drawing.

Indeed. Also. That warning means So here maybe more characters.

Do all your UI in a web browser and just let LabVIEW be a back-end. I switched a couple of years ago and all LabVIEWs UI problems are moot now. I've even been experimenting with "Rainmeter" to break out of the browser frame and utilise the desktop-works great!

If they don't listen to their guru, Linus Torvalds, they deserve "snarky" comments as far as I'm concerned. Let's be clear, here. It is a community problem that Python is just the tip of the iceberg and perpetuates because of its ubiquitous use. I have many Linux friends that complain like hell that games are often not ported to Linux and when I tell them why, they get all defensive and demand cross-platform developers yield and point blank refuse to improve the platform (even though they have the skills to do so). When seeking support, after being told to read the manual, I am always told to patch/port it myself, send it to them and they "will think about it". So ...... what is good for the goose is good for the gander, right? (Not the guys/gals who maintain CMake. They are a drop of water in the dessert) As you will probably be aware, most of my toolkits are backwards compatible to 2009 and work on Windows, Mac and Linux (mainly due to LabVIEWs guarantee) but I removed support for Linux with those that use external libraries for exactly these reasons. I wouldn't blame you in the slightest for putting LabPython back into your private toolbox because it is more hassle than it is worth and they (the Linux community) aren't prepared to give an inch to improve the platform. Of course. They could ask you or your employer for a quote to upgrade to a certain Python version on a particular distribution version. Perhaps start a Kickstarter campaign?

LabVIEW ignores frame rates less than 1 second (greater is OK) and doesn't support extension blocks.

Right. But you just recompile from source because it is so powerful

Right. Are you saying no-one should be using it at all? Using Python 2.3 should be OK, yes? All this is basically saying "you can't" to the original question and "here are some alternatives". But the OP wants to generate a LabVIEW event with Python. I don't like changing the requirements to fit the code. However. Saying that. I could knock up the TCPIP in a few minutes in LabVIEW by just wrapping the generate event primitive ..... so I can see the appeal.

It's not as straightforward as that. The issues are fairly straight forward to resolve for any one version but since the Linux community don't see any problem with breaking ABIs at the drop of a hat and that backwards compatibility is a fairy tale; Rolf has already lost the battle for keeping it current, requiring significant effort with almost every release. If I was in his shoes, I would make it 64 bit compliant, make all the CLFNs orange nodes and tell the users they have to use a specific version of Python or patch it themselves (it's open source after all). Then freeze it for others to champion. Why should Rolf shoulder the problems caused by the intransigence of a completely different language that is nowhere near as disciplined as he or NI are? Unless Rolf has a business need in one of his projects, this is just a millstone caused by open source altruism. We can hope he finds the time and energy to update it but I suspect he would have done so already if that was the case. This is Rolfs very polite way of saying "here are all the problems I know about, fix it yourself if you are good enough".

I've always wanted the Val (Sgnl) property node to fire when new data arrives at the control as well as when the user clicks on it so that I could use events instead of a VI.

There is also != with a shift register/feedback node. That is the common method for detecting change in a sub VI - poor-mans On_Change event.

That is pretty weak. For non enums (rings etc) the default can be anything that's not in the list and use the default frame of a case structure. It is at least visible to the maintainer by inspection of the diagram. For enums, adding an extra entry is non-sensical? (You could have used "OFF", "N/A" or any number of words to make more sense) The proposed alternative is a "setting" on terminals that changes the behaviour so that you have to know has been set.? Does this mean that "style" would then be to have a statement on the digram that the setting is in play since there is no code indication?

Doesn't LabPython run from within the LabVIEW process?

You can call the "PostLVUserEvent" in the functions exported by the LabVIEW executable. The C prototype is in <LabVIEW Version>\cintools\extcode.h so you can see what parms you need. TH_REENTRANT EXTERNC MgErr _FUNCC PostLVUserEvent(LVUserEventRef ref, void *data);

This sounds like a code smell. I don't think I have ever done that. Is this something to do with classes requiring the same connector for overrides?

I'm not sure I'm understanding this fully. Programmable inputs? How would they be programmed-isn't that what our code is for? Going off half-cocked, as per usual, I could perhaps see a benefit of dynamically loading (plugins, DLLs etc) whereby you could define a list of files/names (so a programmable path input control) and somehow it would figure out which one to use. For example a path input on the CLFN that would load a 32 or 64 bit DLL depending on the LabVIEW version - so a kind of conditional path. But like I said, I'm not sure I know what you are getting at so perhaps give a concrete example in another language or a piece of LV code that would benefit from this feature.

Multi-tasking <> multithreading. You seem to be conflating many different aspects of application execution.

The HDF5 library uses recursive locks and keeps a separate error stack for each thread.

Strings are tricksy since there are a few ways that it can be done and sometimes dependent on how the DLL was created. Here is an example. Call Generator2.vi

It's not a choice and it is always needed. You need to invert your view of who is locking who.

Well. The libraries state categorically that you need callbacks when using multithreading and give the code that is required for you to implement (I've just outlined why it is the case and why you can't in LabVIEW). I can only tell you what I know from successfully implementing quite a few different ones; I'm not here convince you.

No it doesn't. I don't know this library but from your description it sounds like it is "thread safe" or single threaded. The developers will have (or should have) made a statement about it somewhere. Well. Serialization means writing binary as strings to me (like the flatten functions,XML etc). So I'm already floundering with your question. Synchronisation maybe? But thread safety isn't about one problem. It is an umbrella term for multiple undefined behaviours when using multiple threads, including race conditions, pointer overflows, memory dereferencing, counter overruns, and lots of nasty stuff that will crash LabVIEW-probably randomly and when already deployed to the customer site. LabVIEW uses thread pools and there is no guarantee that a node will use the same thread from the pool for every call of a particular node. Unfortunately (or fortunately, depending on your perspective). Most of the time LabVIEW tries to use the same thread if it is available, for performance reasons, so for the most part everything seems to work great - right up until it doesn't. So I hope you can see that it really doesn't matter what you do in the LabVIEW code with DVRs, semaphores and other native synchronisation methods. The only guaranteed solutions are to use a thread safe library, use the "Run In UI Thread" or, if the developers have supplied a callback mechanism, use an intermediary library to mediate.