ShaunR

No. It will wait until you have closed the dialogue. If you want it to run independently you will need to dynamically load it.

I wouldn't use Python for this just like I wouldn't use PHP - right tool for the right job and with NI support, which is second to none.

HMI_PopUp_KB has one (HMI Pop Up Num KP.vi). You just need to place it in the Mouse Up event.

Plotly is a rest API (V1, V2). You don't need (nor should want) Python. Just use the HTTP VIs in LabVIEW.

The DVR is a container that enables you to access data via a refnum (so you can pass around the reference rather than make copies of the data). It is not a pointer but has some analogies. You will notice that there is a "data value" output of the delete primitive which returns the contained data when the container is destroyed and, if you inspect this data, you will find the incremented value. .

Well. The Celeron is probably a quad core and the Atom you describe is a dual core but you might also look at the Ethernet port since most budget boards use 10/100 rather than Gb ethernet.

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.