LabVIEW access to stdout and stderr

[Dlauria]

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

[rtollert]

---

@Dlauria wrote:

read from... the stdout and stderr streams

---

Interesting idea, but.. eww, no? You're asking for LabVIEW to, like, replace the existing stdout and stderr with pipes, and manually tee writes to those fds to the real stdout/stderr? (Or something equally if not more heinous on Windows?) That strikes me as the sort of thing that most people would want to keep LabVIEW away from. 😀

AFAIK, on Windows, there is already an appropriate and optimal solution for this problem and that is ETW. On Linux/MacOS, you already had trivial access to the console. (And on all operating systems, Write to System Log.vi already writes to something which for medium-volume logging is possibly also appropriate for your uses — either the Windows Event Log, or syslog.)

If you are trying to integrate literally a (Win32) DLL which demands literally a console, I'm not sure there is anything LabVIEW can do about that. It's not particularly a thing for GUI Win32 apps.

[wiebe@CARYA]

And the other way around: if you use a LabVIEW dll in another language, you should be able to pass the stdin\stdout\stderr reference to the dll, and call the stdin\stdout\stderr from the LabVIEW dll.

I think most would prefer a wrapper application that routes the command line to named pipes, and then read\write to those pipes. TCP\IP or even memory mapped files could be used in stead of pipes.

[IlluminatedG]

I think the key point here would be changing LabVIEW so there's an option where it doesn't immediately disconnect from the console session and we don't need crutch tooling like LabVIEW-CLI, G-CLI, or other console libraries that all have their limitations to interact with a console session. I don't think any of these existing tools solve the problem, they're merely band aids on what I suggest is missing capability.